Skip to main content

Full text of "DTIC ADA198881: Ada (Trademark) Compiler Validation Summary Report: Certificate Number 871209S1.09015, Digital Equipment Corporation VAX Ada, Version 1.5. Host: VAX 8800 under VAX/VMS, Version 4.7. Target: MicroVAX II under VAXELN Toolkit, Version 3.0 in Combination with VAXELN Ada, Version 1.2"

See other formats


AD-A198 881 



OTIC FILE COW ’ g) 


AVF Control Number: NBS87VDEC540 2 


Ada Compiler 

VALIDATION SUMMARY REPORT: 

Certificate Number: 871209S1.09015 
Digital Equipment Corp. 

VAX Ada, Version 1.5 

The host environment is the VAX 8800 under VAX/VMS, Version 
4.7. The target environment is the MicroVAX II (under VAXELN 
Toolkit, Version 3.0 in combination with VAXELN Ada, Version 
1 . 2 ) 


Completion of On-Site Testing: 
09 Dec 1987 


Prepared By: 

Software Standards Validation Group 
Institute for Computer Sciences and Technology 
National Bureau of Standards 
Building 225, Room A266 
Gaithersburg, Maryland 20899 


DTIC 

—LEC, ? 

SEP 0 11988 






Prepared For: 

Ada Joint Program Office 
United States Department of Defense 
Washington, D.C. 20301-3081 


y DISTRIB UTION STATEMENT a. I 
I Appip^ed for public xeleoMl j 
Distribution Unlimited 


88 8 31 018 



UNCLASSIFIED 


'SECURITY CLASSIFICATION of THIS PACE (When Pete Entered 


REPORT DOCUMENTATION PAGE 

READ INSTRUCTIONS 

BEFORE COMPLETEINO FORM 

1. REPORT NUMBER |2. GOVT ACCESSION NO. 

3. RECIPIENT'S CATALOG NUMBER 

4. TITLE (and Subtitle) 

Ada Compile^ Validation Summary Report: 

Digital Equipment Corp.,VAX ada, Version 1.5, 
VAX 8^00 (Host) , and MicroVAX II under VAXELN 
Toolkit with VAXELN Ada (Target). 

5. TYPE OF REPORT & PERIOD COVEREO 

9 Dec 1987 to 9 Oec 1988 

6. PERFORMING 0RG. REPORT NUMBER 

7. AUTHORS) 

National Bureau of Standards, 

Gaithersburg, Maryland, U.S.A. 

8. CONTRACT OR GRANT NUMBER!*; 

S. PERFORMING ORGANIZATION AND AOORESS 

National Bureau of Standards, 

Gaithersburg, Maryland, U.S.A. 

10. PROGRAM ELEMENT. PROJECT. TASK 
AREA i WORK UNIT NUMBERS 

11. CONTROLLING OFFICE NAME AND AOORESS 

Ada Joint Program Office 

United States Department of Defense 

Washington, DC 20301-3081 

12. REPORT DATE 

9 December 1987 


14. MONITORING AGENCY NAME & AD0RESS(/F different from Controlling Office) 

National Bureau of Standards, 

Gaithersburg, Maryland, U.S.A. 

15. SECURITY CLASS (of this report) 

UNCLASSIFIED 

15«. g£j^gjjj>£FICATI0N/D0WNGRADING 

N/A 

IS. DISTRIBUTION STATEMENT (of this Report) 

Approved for public release; distribution unlimited. 

17. DISTRIBUTION STATEMENT (of the abstract entered in Block 20. If different from Report) 

UNCLASSIFIED 

18. SUPPLEMENTARY NOTES 

19. KEYWORDS (Continue on reverse side if necessary and identify by block number) 

l 

Ada Programming language, Ada Compiler Validation Summary Report, Ada 
Compiler Validation Capability, ACVC, Validation Testing, Ada 

Validation Office, AVO, Ada Validation Facility, AVF, ANSI/MIL-STD- 
1815A, Ada Joint Program Office, AJPO 

20. ABSTRACT (Continue on reverse side if necessary and identify by block number) 

VAX Ada, Version 1.5, Digital Equipment Corp., National Bureau of Standards, VAX 8800 (Host) under 
VAX/VMS, Version 4.7 and MicroVAX II under VAXELN Toolkit, Version 3.0 in combination with VAXELN 

Ada, Version 1.2 (Target), ,ACVC 1.9. 


00 FW * 1473 COITION OF 1 NOV 65 IS OBSOLETE 


I JA* 73 S/N 0102-LF-014-6801 _ UNCLASSIFIED 


SECURI'Y CLASSIFICATION OF THIS PAGE (WhenData entered) 


H. 


t- 




























Ad* Compiler Validation Summary Report: 

Compiler'Name: VAX Ada, Version 1.5 

Certificate Number: 871209S1.09015 

Host: VAX 8800 under VAX/VMS, Version 4.7 

Target: MicroVAX II under VAXELN Toolkit, Version 3.0 in 

combination with VAXELN Ada, Version 1.2 

Testing Completed 09 Dec 1987 Using ACVC 1.9 

This report has been reviewed and is approved. 



Chief, Information Systems 
Engineering Division 
National Bureau of Standards 
Gaithersburg, MD 20899 


Organization 
Dr. John F. Kramer 
Institute for Defense Analyses 
Alexandria, VA 22311 




4 


Ada Validation 


Ksrtia ) 

Ada Joint Program Office 
Virginia L. Castor 
Director 

Department of Defense 
Washington DC 20301 


AcCesion For 

NTIS CRAAI 
OTIC TAB - 

Unsii>r<o'!i\.t'd 

JtlSlifiCJtiOil 



% 

DiUibuii'.::./ 


AwaitabftiJy Codes 
; Av 5i! J:'dl OI 



f *T|Q 









EXECUTIVE SUMMARY 


This Validation Summary Report (VSR) summarizes the results and 
conclusions of validation testing performed on the VAX Ada, Version 1.5, 
using Version 1.9 of the Ada Compiler Validation Capability (ACVC). VAX 
Ada is hosted on a VAX 8800 operating under VAX/VMS, Version 4.7. 
Programs processed by this compiler may be executed on: 

MicroVAX II under VAXELN Toolkit, Version 3.0 in 
combination with VAXELN Ada, Version 1.2 

On-site testing was performed 07 Dec 1987 through 09 Dec 1987 at Nashua, 
NH, under the direction of the Software Standards Validation Group, 
Institute for Computer Sciences and Technology, National Bureau of 
Standards (AVF), according to Ada Validation Organization (AVO) policies 
and procedures. At the time of testing, version 1.9 of the ACVC 
comprised 3122 tests of which 25 had been withdrawn. Of the remaining 
tests, 92 were determined to be inapplicable to this implementation. 
Results for processed Class A, C, D, and E tests were examined for 
correct execution. Compilation listings for Class B tests were analyzed 
for correct diagnosis of syntax and semantic errors. Compilation and 
link results of Class L tests were analyzed for correct detection of 
errors. The remaining 3005 tests were passed. The results of 
validation are summarized in the following table: 


RESULT 

— 1 

—2 

CHAPTER 

4 _5 6 7 8 9 10 11 12 13 14 

TOTAL 

Passed 

185 

553 

657 245 

166 

98 141 326 137 

36 

234 

3 

224 

3005 

Failed 

0 

0 

0 0 

0 

0 0 0 0 

0 

0 

0 

0 

0 

Inapplicable 

19 

20 

18 3 

0 

0 2 10 

0 

0 

0 

29 

92 

Withdrawn 

2 

13 

2 0 

0 

12 0 0 

0 

2 

1 

2 

25 

TOTAL 

206 

586 

677 248 

166 

99 145 327 137 

36 

236 

4 

255 

3122 


The AVF concludes that these results demonstrate acceptable conformity 
to ANSI/MIL-STD-1815A Ada. . 


i 







TABLE OF CONTENTS 


CHAPTER 1 


CHAPTER 2 


CHAPTER 3 


3.7.1 

3.7.2 

3.7.3 


APPENDIX A 


APPENDIX B 


APPENDIX C 


APPENDIX D 


INTRODUCTION 


PURPOSE OF THIS VALIDATION SUMMARY REPORT .... 1-2 

USE OF THIS VALIDATION SUMMARY REPORT.1-2 

REFERENCES.1-3 

DEFINITION OF TERMS.1-3 

ACVC TEST CLASSES.1-4 


CONFIGURATION INFORMATION 

CONFIGURATION TESTED . 2-1 

IMPLEMENTATION CHARACTERISTICS . 2-1 


TEST INFORMATION 

TEST RESULTS.3-1 

SUMMARY OF TEST RESULTS BY CLASS. .3-1 

SUMMARY OF TEST RESULTS BY CHAPTER.3-2 

WITHDRAWN TESTS . 3-2 

INAPPLICABLE TESTS . 3-2 

TEST, PROCESSING, AND EVALUATION MODIFICATIONS . . 3-4 

ADDITIONAL TESTING INFORMATION . 3-4 

Prevalidation.3-5 

Test Method.3-5 

Test Site .. 3-6 


CONFORMANCE STATEMENT 


APPENDIX F OF THE Ada STANDARD 


TEST PARAMETERS 


WITHDRAWN TESTS 


Ik'.H 


h.»r» 


I ft 























CHAPTER 1 


INTRODUCTION 


This /i*l tdat ion Summary Report /tVSRT describes the extent to which a 
specific Ada compiler conforms to the Ada Standard, ANSI/MIL-STD-1815A. 
This report explains all technical terms used within it and thoroughly 
reports the results of testing this compiler using the Ada Compiler 
Validation Capability (ACVC). An Ada compiler must be implemented 
according to the Ada Standard, and any implementation-dependent features 
must conform to the requirements of the Ada Standard. The Ada Standard 
must be implemented in its entirety, and nothing can be implemented that 
is not in the Standard. ) 


Even though all validated Ada compilers conform to the Ada Standard, it 
must be understood that some differences do exist between 
implementations. The Ada Standard permits some implementation 
dependencies--for example, the maximum length of identifiers or the 
maximum values of integer types. Other differences between compilers 
result from the characteristics of particular operating systems, 
hardware, or implementation strategies. All the dependencies observed 
during the process of testing this compiler are given in this report. ^ 

This Information in this report is derived from the test results 
produced during validation testing. The validation process includes 
submitting a suite of standardized tests, the ACVC, as inputs to an Ada 
compiler and evaluating the results. The purpose of validating is to 
ensure conformity of the compiler to \he Ada Standard by testing that 
the compiler properly implements legal\language constructs and that it 
identifies and rejects illegal language constructs. The testing also 
identifies behavior that is implementation dependent but permitted by 
the Ada Standard. Six classes of test are used. These tests are 
designed to perform checks at compile time, at link time, and during 
execution. \ 








1.1 PURPOSE OF THIS VALIDATION SUMMARY REPORT 

This VSR documents Che results of the validation testing performed on an 
Ada compiler. Testing was carried out for the following purposes: 

To attempt to identify any language constructs supported by 
the compiler that do not conform to the Ada Standard 

To attempt to identify any unsupported language constructs 
required by the Ada Standard 

To determine that the implementation-dependent behavior is 
allowed by the Ada Standard 


On-site testing was conducted from 07 Dec 1987 through 09 Dec 1987 at 
Nashua, NH. 


1.2 USE OF THIS VALIDATION SUMMARY REPORT 

Consistent with the national laws of the originating country, the AVO 
may make full and free public disclosure of this report. In the United 
States, this is provided in accordance with the "Freedom of Information 
Act" (5 U.S.C. #552). The results of this validation apply only to 
the computers, operating systems, and compiler versions identified in 
this report. 

The organizations represented on the signature page of this report do 
not represent or warrant that all statements set forth in this report 
are accurate and complete, or that the subject compiler has no 
nonconformities to the Ada Standard other than those presented. Copies 
of this report are available to the public from: 

Ada Information Clearinghouse 
Ada Joint Program Office 
OUSDRE 

The Pentagon, Rm 3D-139 (Fern Street) 

Washington DC 20301-3081 

or from: 

Software Standards Validation Group 
Institute for Computer Sciences and Technology 
National Bureau of Standards 
Building 225, Room A266 
Gaithersburg, Maryland 20899 

Questions regarding this report or the validation test results should be 


1-2 







directed to the AVF listed above or to: 


Ada Validation Organization 
Institute for Defense Analyses 
1801 North Beauregard Street 
Alexandria VA 22311 


1.3 REFERENCES 


1. Reference Manual for the Ada Programming Language. 

ANSI/MIL-STD-1815A, February 1983. 

2. Ada Compiler Validation Procedures-find Guidelines . Ada Joint 
Program Office, 1 January 1987. 

3. Ada Compiler Validation Capability Imolenienters’ Guide. 
SofTech, Inc., December 1986. 


1.4 DEFINITION OF TERMS 


ACVC The Ada Compiler Validation Capability. The set of Ada 

programs that tests the conformity of an Ada compiler to 
the Ada programming language. 

Ada Commentary An Ada Commentary contains all information relevant to 
the point addressed by a comment on the Ada Standard. 
These comments are given a unique identification number 
having the form AI*ddddd. 


Ada Standard ANSI/MIL-STD-1815A, February 1983. 


Applicant 

AVF 


AVO 


The agency requesting validation. 

The Ada Validation Facility. In the context of this 
report, the AVF is responsible for conducting compiler 
validations according to established procedures. 

The Ada Validation Organization. In the context of 
this, report, the AVO is responsible for establishing 
procedures for compiler validations. 


A processor for the Ada language. In the context of 
this report, a compiler is any language processor, 
including cross'compilers, translators, and 
interpreters. 


Compiler 




Failed test 


Host 

Inapp'icable 
test 


An ACVC test for which the compiler generates a result 
that demonstrates nonconformity to the Ada Standard. 

The computer on which the compiler resides. 

An ACVC test that uses features of the language that a 
compiler is not required to support or may legitimately 
support in a way other than the one expected by the 
test. 


Language 

Maintenance 


The Language Maintenance Panel (LMP) is a committee 
established by the Ada Board to recommend 
interpretations and Panel possible changes to the 
ANSI/MIL-STD for Ada. 


Passed test An ACVC test for which a compiler generates the expected 
result. 


Target 

Test 


Vithdrawn 

test 


The computer for which a.compiler generates code. 

An Ada program that checks a compiler's conformity 
regarding a particular feature or a combination of 
features to the Ada Standard. * In the context of this 
report, the term is used to designate a single test, 
which may comprise one or more files. 

An ACVC test found to be incorrect and not used to check 
conformity to the Ada Standard. A test may be incorrect 
because it has an invalid test objective, fails to meet 
its test objective, or contains illegal or erroneous use 
of the language. 


1.5 ACVC TEST CLASSES 

Conformity to the Ada Standard is measured using the ACVC. The ACVC 
contains both legal and illegal Ada programs structured into six test 
classes: A, B, C, D, E, and L. The first letter of a test name 
identifies the class to which it belongs. Class A, C, D, and E tests 
are executable, and special program units are used to report their 
results during execution. Class B tests are expected to produce 
compilation errors. Class L tests are expected to produce link errors. 

Class A tests check that legal Ada programs can be successfully compiled 
and executed. However, no checks are performed during execution to see 
if the test objective had been met. For example, a Class A test checks 
that reserved words of another language (other than those already 
reserved in the Ada language) are not treated as reserved words by an 
Ada compiler. A Class A test is passed if no errors are detected at 
compile time and the program executes to produce a PASSED message. 





Class B casts check ChaC a compiler detects illegal language usage. 
Class B tests are not executable. Each test in this class is compiled 
and the resulting compilation listing is examined to verify that every 
syntax or semanfic error in the test is detected. A Class B test is 
passed if every illegal construct that it contains is detected by the 
compiler. 

Class C tests check that legal Ada programs can be correctly compiled 
and executed. Each Class C test is self'Checking and produces a PASSED, 
FAILED, or NOT APPLICABLE message indicating the result when it is 
executed. 

Class D tests check the compilation and execution capacities of a 
compiler. Since there are no capacity requirements placed on a compiler 
by the Ada Standard for some parameters "for example, the number of 
identifiers permitted in a compilation or the number of units in a 
library--a compiler may refuse to compile a Class D test and still be a 
conforming compiler. Therefore, if a Class D test fails to compile 
because the capacity of the compiler is exceeded, the test is classified 
as inapplicable. If a Class D test compiles successfully, it is 
self-checking and produces a PASSED or FAILED message during execution. 

Each Class E test is self-checking and produces a NOT APPLICABLE, 
PASSED, or FAILED message when it is compiled and executed. However, 
the Ada Standard permits an implementation to reject programs containing 
some features addressed by Class E tests during compilation. Therefore, 
a Class E test is passed by a compiler if it is compiled successfully 
and executes to produce a PASSED message, or if it is rejected by the 
compiler for an allowable reason. 

Class L tests check that Incomplete or illegal Ada programs involving 
multiple, separately compiled units are detected and not allowed to 
execute. Class L tests are compiled separately and execution is 
attempted. A Class L test passes if it is rejected at link time--that 
is, an attempt to execute the main program must generate an error 
message before any declarations in the main program or any units 
referenced by the main program are elaborated. 

Two library units, the package REPORT and the procedure CHECK FILE, 
support the self-checking features of the executable tests. The package 
REPORT provides the mechanism by which executable tests report PASSED, 
FAILED, or NOT APPLICABLE results. It also provides a set of identity 
functions used to defeat some compiler optimizations allowed by the Ada 
Standard that would circumvent a test objective. The procedure CHECK 
FILE is used to check the contents of text files written by some of the 
Class C tests for chapter 14 of the Ada Standard. The operation of 
these units is checked by a set of executable tests. These tests 
produce messages that are examined to verify that the units are 
operating correctly. If these units are not operating correctly, then 
the validation is not attempted. 






The text of the tests in the ACVC follow conventions that are intended 
to ensure that the tests are reasonably portable without modification. 
For example, the tests make use of only the basic set of 55 characters, 
contain lines with a maximum length of 72 characters, use small numeric 
values, and pTace features that may not be supported by all 
implementations in separate tests. However, some tests contain values 
that require the test to be customized according to 
implementation*specific values--for example, an illegal file name. A 
list of the values used for this validation is provided in Appendix C. 

A compiler must correctly process each of the tests in the suite and 
demonstrate conformity to the Ada Standard by either meeting the pass 
criteria given for the test or by showing that the test is inapplicable 
to the implementation. The applicability of a test to an implementation 
is considered each time the implementation is validated. A test that is 
inapplicable for one validation is not necessarily inapplicable for a 
subsequent validation. Any test that was determined to contain an 
illegal language construct or an erroneous language construct is 
withdrawn from the ACVC and, therefore, is not used in testing a 
compiler. The tests withdrawn at the time of validation are given in 
Appendix D. 





CHAPTER 2 


CONFIGURATION INFORMATION 


2.1 CONFIGURATION TESTED 

The candidate compilation system for this validation was tested under 
the following configuration: 


Compiler: VAX Ada, Version 1.5 
ACVC Version: 1.9 

Certificate Number: 871209S1.09015 

Host Computer: 

Machine: VAX 8800 

Operating System: VAX/VMS, Version 4.7 

Memory Size: 68Mbytes 

Target Computer: 

Machine: Operating System: Memory Size: 

MicroVAX II VAXELN Toolkit, Version 3.0 9Mbytes 

in combination with VAXELN 
Ada, Version 1.2 

Communications Network: ; DECnet and a RC-25 

removable disk 


2.2 IMPLEMENTATION CHARACTERISTICS 

One of the purposes of validating compilers is to determine the behavior 
of a compiler in those areas of the Ada Standard that permit 
Implementations to differ. Class D and E tests specifically check for 
such implementation differences. However, tests in other classes also 
characterize an implementation. The tests demonstrate the following 
characteristics: 


2-1 





Capacities. 


The compiler correctly processes tests containing loop 
statements nested to 65 levels, block statements nested to 65 
levels, and recursive procedures separately compiled as subunits 
nested to 17 levels. It correctly processes a compilation 
containing 723 variables in the same declarative part. (See 
test D55A03A..H (8 tests), D56001B, D64005E..G (3 tests), and 
D29002K.) 


Universal integer calculations. 

An implementation is allowed to reject universal integer 
calculations having values that exceed SYSTEM.MAX_INT. This 
Implementation processes 64 bit integer calculations. (See 
tests D4A002A, D4A002B, D4A004A, and D4A004B.) 


Predefined types. 

This implementation supports the additional predefined types 
SHORT_INTEGER, LONG_FLOAT, and SHORT_SHORT_INTEGER in the 
package STANDARD. (See tests B86001BC and B86001D.) 


- Based literals. 

An implementation is allowed to reject a based literal with a 
value exceeding SYSTEM.MAX_INT during compilation, or it may 
raise NUMERIC_ERROR or CONSTRAINT_ERROR during execution. This 
implementation raises NUMERIC ERROR during execution. (See test 
E24101A.) 


- Expression evaluation. 

Apparently all default initialization expressions or record 
components are evaluated before any value is checked to belong 
to a component's subtype. (See test C32117A.) 

Assignments for subtypes are performed with the same precision 
as the base type. (See test C35712B.) 

This implementation uses no extra bits for extra precision. 
This implementation uses all extra bits for extra range. (See 
test C35903A.) 


2-2 







Apparently NUMERIC_ERROR is raised when an integer literal 
operand in a comparison or membership test is outside the range 
of.the base type. (See test C45232A.) 

Apparently NUMERIC_ERROR is raised when a literal operand in a 
fixed point comparison or membership test is outside the range 
of the base type. (See test C45252A.) 

Apparently underflow is not gradual. (See tests C45524A..Z.) 

- Rounding. 

The method used for rounding to integer is apparently round away 
from zero. (See tests C46012A..Z.) 

The method used for rounding to longest integer is apparently 
round away from zero. (See tests C46012A..Z.) 

The method used for rounding to integer in static universal real 
expressions is apparently round away from zero. (See test 
C4A014A.) 

Array types. 

An implementation is allowed to raise NUMER1CERROR or 
CONSTRAINT_ERROR for an array having a 'LENGTH that exceeds 
STANDARD. INTEGER'LAST and/or SYSTEM. MAX_INT. For this 
implementation: 

Declaration of an array type or subtype declaration with more 
than SYSTEM.MAX_INT components raises NUMERIC ERROR. (See test 
C36003A.) 

NUMERIC_ERROR is raised when 'LENGTH is applied to an array type 
with INTEGER*LAST + 2 components. NUMERIC_ERROR is raised when 
an array type with INTEGER'LAST + 2 components is declared. 
(See test C36202A.) 

NUMERIC ERROR is raised when 'LENGTH is applied to an array type 
with SYSTEM.MAX_INT + 2 components. NUMERIC_ERROR is raised 
when an array type with SYSTEM. MAX_INT + 2 components is 
declared. (See test C36202B.) 

A packed BOOLEAN array having a 'LENGTH exceeding INTEGER'LAST 
raises NUMERIC ERROR when the array type is declared. (See test 
C52103X.) 

A packed two-dimensional BOOLEAN array with more than 
INTEGER'LAST components raises NUMERIC__ERROR when the array type 
is declared. (See test C52104Y.) 


2-3 








A null array with one dimension of length greater than 
INTEGER'LAST may raise NUMERIC_ERROR or C0NSTRAINT_ERR0R either 
when declared or assigned. Alternatively, an implementation may 
accept the declaration. However, lengths must match in array 
slice assignments. This implementation raises NUMERIC_ERROR 
when the array type is declared. (See test E52103Y.) 

In assigning one‘dimensional array types, the expression appears 
to be evaluated in its entirety before CONSTRAINT_ERROR is 
raised when checking whether the expression's subtype is 
compatible with the target's subtype. In assigning 
two-dimensional array types, the expression does not appear to 
be evaluated in its entirety before CONSTRAINT_ERROR is raised 
when checking whether the expression's subtype is compatible 
with the target's subtype. (See test C52013A.) 


- Discriminated types. 

During compilation, an implementation is allowed to either 
accept or reject an incomplete type with discriminants that is 
used in an access type definition with a compatible discriminant 
constraint. This Implementation accepts such subtype 
indications. (See test E38104A.) 

In assigning record types with disciminants, the expression 
appears to be evaluated in its entirety before C0NSTRAINT_ERR0R 
is raised when checking whether the expression's subtype is 
compatible with the target's subtype. (See test C52013A.) 


- Aggregates. 

In the evaluation of a multi-dimensional aggregate, all choices 
appear to be evaluated before checking against the index type. 
(See tests C43207A and C43207B.) 

In the evaluation of an aggregate containing subaggregates, all 
choices are evaluated before being checked for identical bounds. 
(See test E43212B.) 

i 

All choices are evaluated before CONSTRAINT_ERROR is raised if a 
bound in a nonnull range of a nonnull aggregate does not belong 
to an index subtype. (See test E43211B.) 


• Representation clauses. 

The Ada Standard does not require an implementation to support 
representation clauses. If a representation clause is not 
supported, then the implementation must reject it. 


2-4 






Enumeration representation clauses containing noncontiguous 

values for enumeration types other than character and boolean 

types are supported. (See tests C3SS02I..J, C35502M..N, and 

A39005F.) 

* 

Enumeration representation clauses containing noncontiguous 
values for character types are supported. (See tests 
C35507I..J, C35507M..N, and C55B16A.) 

Enumeration representation clauses for boolean types containing 
representational values other than (FALSE -> 0, TRUE -> 1) are 
not supported. (See tests C35508I..J and C35508M..N.) 

Length clauses with SIZE specifications for enumeration types 
are supported. (See test A39005B.) 

Length clauses with STORAGE_SIZE specifications for access types 
are supported. (See tests A39005C and C87B62B.) 

Length clauses with STORAGE_SXZE specifications for task types 
are supported. (See tests A39005D and C87B62D.) 

Length clauses with SMALL specifications are supported. (See 
tests A39005E and C87B62C.) 

Length clauses with SIZE specifications for derived Integer 
types are supported. (See test C87B62A.) 


- Pragmas. 

The pragma'INLINE is supported for procedures. The pragma 
INLINE is supported for functions. (See tests LA3004A, 
LA3004B, EA3004C, EA3004D, CA3004E, and CA3004F.) 


• Input/output. 

The package SEQUENTIAL_IO can be instantiated with unconstrained 
array types and record types with discriminants without 
defaults. (See tests AE2101Q, EE2201D, and EE2201E.) 

By default, the package DIRECT_I0 cannot be instantiated with 
unconstrained array types and record types with discriminants 
without defaults. (See tests EE2401D and EE2401G.) 

There are strings which are illegal external file names for 
SEQUENTIAL_I0 and DIRECT_I0. (See tests CE2102C and CE2102H.) 

Mode IN FILE is supported for SEQUENTIAL 10. (See test 

CE2102D.7 






Mode OUT FILE is supported for SEQUENTIAL 10. (See test 
CE2102E.)~ 

Modes OUT FILE and INOUT FILE are supported for DIRECT_IO. (See 
tests CE2102F and CE2102J.) 

Mode IN_FILE is supported for DIRECT_I0. (See test CE2102.) 

RESET and DELETE are supported for SEQUENTIAL_I0 and DIRECT_I0. 
(See tests CE2102G and CE2102K.) 

Dynamic creation and deletion of files are supported for 
(SEQUENTIAL_I0 and DIRECT_I0. (See tests CE2106A and CE2106B.) 

Overwriting to a sequential file truncates the file to last 
element written. (See test CE2208B.) 

An existing text file can be opened in 0UT_FILE mode, can be 
created in OUTFILE mode, and can be created IN_FILE mode. (See 
test EE3102C.) 

By default only one internal file can be associated with each 
external file for text I/O for both reading and writing. (See 
tests CE2110B, CE2111D, CE3111A..E (5 tests), CE3114B, and 

CE3115A.) 

More than one internal file can be associated with each external 
file for sequential I/O for reading only. (See test CE2107A.) 

More than one internal file can be associated with each external 
file for direct I/O for reading only. (See tests CE2107F.) 

Temporary sequential files are not given names. Temporary 
direct files are not given names. (See tests CE2108A and 
CE2108C.) 

- Generics. 

Generic subprogram declarations and bodies can compiled in 
separate compilations. (See tests CA1012A and CA2009F.) 

Generic package declarations and bodies can be compiled in 
separate compilations. (See tests CA2009C, BC3204C, and 

BC3205D.) 

Generic unit bodies and their subunits can be compiled in 
separate compilations. (See test CA3011A.) 





1 


9 

CHAPTER 3 
TEST INFORMATION 


3.1 TEST RESULTS 

At the time of testing, version 1.9 of the ACVC comprised 3122 tests of 
which 25 had been withdrawn. Of the remaining tests, 92 were determined 
to be inapplicable to this implementation. 

The AVF concludes that the testing results demonstrate acceptable 
conformity to the Ada Standard. 


3.2 SUMMARY OF TEST RESULTS BY CLASS 


RESULT 

A 

TEST CLASS 

_B_C_D_ 

E 

L 

TOTAL 

Passed 

108 

1048 

1770 

17 

16 

46 

3005 

Failed 

0 

0 

0 

0 

0 

0 

0 

Inapplicable 

2 

3 

85 

0 

2 

0 

92 

Withdrawn 

3 

2 

19 

0 

1 

0 

25 

TOTAL 

113 

1053 

1874 

17 

19 

46 

3122 


3-1 





3.3 SUMMARY OF TEST RESULTS BY CHAPTER 


RESULT CHAPTER TOTAL 

_ _ 1 _ l _ k _ i _6 _I _& _2 _li _U -11 _i£ _ 


Passed 

185 

553 

657 

245 

166 

98 

141 

326 

137 

36 

234 

3 

224 

3005 

Failed 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

Inapplicable 

19 

20 

18 

3 

0 

0 

2 

1 

0 

0 

0 

0 

29 

92 

Withdrawn 

2 

13 

2 

0 

0 

1 

2 

0 

0 

0 

2 

1 

2 

25 

TOTAL 

206 

586 

677 

248 

166 

99 

145 

327 

137 

36 

236 

4 

255 

3122 


3.4 WITHDRAWN TESTS 

The following 25 tests were withdrawn from ACVC Version 1.9 at the time 
of this validation: 


B28003A 

E28005C 

C34004A 

C35502P 

A35902C 

C35904A 

C35A03E 

C35A03R 

C37213H 

C37213J 

C37215C 

C37215E 

C37215G 

C37215H 

C38102C 

C41402A 

C45614C 

A74106C 

C85018B 

C87B04B 

CC1311B 

BC3105A 

AD1A01A 

CE2401H 


CE3208A 

See Appendix D for the reason that each of these tests was withdrawn. 


3.5 INAPPLICABLE TESTS 

Some tests do not apply to all compilers because they make use of 
features that a compiler is not required by the Ada Standard to support. 
Others may depend on the result of another test that is either 
inapplicable or withdrawn. The applicability of a test to an 
implementation is considered each time a validation is attempted. A 
test that is inapplicable for one validation attempt is not necessarily 
inapplicable for a subsequent attempt. For this validation attempt, 92 
test were inapplicable for the reasons indicated: 


C24113H. .Y (18 tests) have source lines that exceed the VAX Ada 
implementation limit of 120 characters. 








A28004A Line 23 contains a pragma INTERFACE for function MEMORY_SIZE 
whose body is declared at line 18; this implementation rejects the 
subprogram body on the basis of the Ada Standard 13.9 (3). The test 
expects the pragma to be ignored due to the language name "ZZZZZZ". The 
AVO temporarily* ruled this test N.A. while the issue is further 
considered. 

C35508I..J (2 tests) and C35508M..N (2 tests) use enumeration 
representation clauses for boolean types containing representational 
values other than (FALSE -> 0, TRUE -> 1). These clauses are not 
supported by this compiler. 

C35702A (and B86001CP which is not included in the above 92 count) use 
SHORT_FLOAT which is not supported by this implementation. 

A39005G specifies a range for a component in a record representation 
clause that is not compatible with the default representation chosen by 
the compiler for the type of the component. 

The following (14) tests use L0NG_INTEGER, which is not supported by 
this compiler. 

C4S231C C45304C C45502C C45503C C45504C C45504F 

C45611C C45613C C45631C C45632C B52004D B55B09C 

C55B07A B86001CS 

The following (22) tests use particular fixed point base types which are 
not supported by this compiler. 

C35902D C35A03B..C C35A030..P C35A04B..C C35A040..P 

C35A06B C35A07B..C C35A070..F C45531I..J C45513M..P 

C45532I..J C45532M..P 

C86001F redefines package SYSTEM, but TEXT_I0 is made obsolete by 
this new definition in this implementation and the test cannot be 
executed since the package REPORT is dependent on the package TEXT_I0. 

C96005B requires the range of type DURATION to be different from those 
of its base type; in this implementation they are the same. 

CE2102E is inapplicable because this implementation supports mode 

0UT_FILE for SEQUENTIAL.I0. 

CE2102F is inapplicable because this implementation supports mode 

INOTJT_FILE for DIRECT_I0. 

CE2102G is inapplicable because this implementation supports RESET for 
SEQUENTIAL_IO. 


CE2102J is inapplicable because this Implementation supports mode 
OUT FILE for DIRECT 10. 




CE2102K is inapplicable because this implementation supports RESET for 
DIRECT_IO. 

CE2105A, CE2105ET, CE2111H, and CE3109A are inapplicable because this 
implementation does not allow the creation of a file of mode IN_FILE. 

CE2107B, CE2107G, CE2110B, CE2111D, CE3111B..E (4 tests). CE3114B, and 
CE3115A are inapplicable because this implementation does not allow more 
than one internal file to be associated with an external file for mode 
INOUTFILE or OUT_FILE in combination with mode IN_FILE or 0UT_F1LE or 
INOUTFILE when default options are used. 

CE2107C..E (3 tests), CE2107H..I (2 tests), CE2108A, CE2108C, and 
CE3112A are inapplicable because for this implementation temporary files 
do not have names. The NAME function raises USE_ERROR (see AI-46). 

EE2401D and EE2401G use instantiations of package DIRECT_IO with 
unconstrained array types and record types having discriminants without 
defaults. These instantiations compiled with no errors, but during 
execution USE ERROR was raised. 


3.6 TEST, PROCESSING, AND EVALUATION MODIFICATIONS 

It is expected that some tests will require modifications of code, 
processing, or evaluation in order to compensate for legitimate 
implementation behavior. Modifications are made with the approval of 
the AVO, and are made in cases where legitimate implementation behavior 
prevents the successful completion of an (otherwise) applicable test. 
Examples of such modifications include: adding a length clause to alter 
the default size of a collection; splitting a Class B test into 
sub-tests so that all errors are detected; and confirming that messages 
produced by an executable test demonstrate conforming behavior that 
wasn't anticipated by the test (such as raising one exception instead of 
another). 

No modifications were required for any of the tests. 

C34007A, C34007D, C34007G, C34007M, jC34007P, and C34007S require that 
the attribute ST0RAGE_S1ZE return a value greater than 1 when applied to 
an access subtype for which no STORAGE_SIZE length clause was provided. 
This requirement is challenged and will be reviewed by the ARG. The AVF 
verified that the failure of these tests was solely attributable to the 
STORAGE_SIZE check, and the AVO ruled that such results should be 
counted as "PASSED". 

C4A012B checks that 0.0 raised to a negative power raises CONSTRAINT^ 
ERROR; however, NUMERIC_ERROR may also be raised, and that is what this 
implementation does. The AVF confirmed this by an analysis of the 
results, and the AVO ruled that such behavior counts as "PASSED”. 


3-4 





3.7 ADDITIONAL TESTING INFORMATION 

3.7.1 Prevalidation 

Prior to validation, a set of test results for ACVC Version 1.9 produced 
by VAX Ada was submitted to the AVF by the applicant for review. 
Analysis of these results deaonstrated that the compiler successfully 
passed all applicable tests, and the compiler exhibited the expected 
behavior on all inapplicable tests. 

3.7.2 Test Method 

Testing of VAX Ada using ACVC Version 1.9 was conducted on-site by a 
validation team from the AVF. The configuration consisted of a VAX 8800 
operating under VAX/VMS, Version 4.7. The target computer was a 
MicroVAX II (under VAXELN Toolkit, Version 3.0 in combination with 
VAXELN Ada, Version 1.2). The files were moved to the target using an 
RC-25 removable disk. 

A magnetic tape containing all tests except for withdrawn tests was 
taken on-site by the validation team for processing. Tests that make 
use of impleisentation-specific values were customized before being 
written to the magnetic tape. Tests requiring modifications during the 
prevalidation testing were included In their modified form on the 
magnetic tape. The contents of the magnetic tape were loaded directly 
onto the host computer. 

After the test files were loaded to disk, the full set of tests was 
compiled and linked on the VAX 8800, and all executable tests were run 
on the MicroVAX II (under VAXELN Toolkit, Version 3.0 in combination 
with VAXELN Ada, Version 1.2). Results were printed from the host 
computer, with results being transferred to the host computer via 
DECnet. 

The compiler was tested using command scripts provided by Digital 
Equipment Corporation and reviewed by the validation team. The compiler 
was tested using all default (option/switch) settings except for the 
following: 


Qattan/Swltcb £££s&i 


/NOCOPY_SOURCE Controls whether the source being compiled is 

copied into the compilation library for a 
successful compilation. 


/N0DEBUG 


Controls the inclusion of debugging symbol 
table information in the compiled object 




module. 


/ERROR_LIMIT-1000 Controls the number of error level diagnostics 

that are allowed within a single compilation 
* unit before the compilation is aborted. 

/LIST Controls whether a listing file is produced. 

/LIST without a filename uses a default 
filename of the form sourcename. LIS, where 
sourcename is! the name of the source file 
being compiled. 

/NOSHOff Controls whether a portability summary is 

included in the listing. 

Tests were compiled, linked, and executed (as appropriate) using a 
single host computer and one target computer. Test output, compilation 
listings, and job logs were captured on magnetic tape and archived at 
the AVF. 


3.7.3 Test Site 

The validation team arrived at Nashua, NH on 07 Dec 1987, and departed 
after testing was completed on 09 Dec 1987. 


3-6 






s 


APPENDIX A 

CONFORMANCE STATEMENT 


The following Declaration of Conformance is provided by DEC for VAX Ada. 
Because the VAXELN targets produce different results than those of the 
VMS targets for three ACVC tests (which require temporary files to have 
names), the VAXELN & VMS operating environments were tested separately, 
«na the testing is thus documented in separate VSRs. However, the AVO 
mda no request for DEC to submit separate Declarations of Conformance. 


A-l 





Declaration of Conformance 


Compiler Implementer: Digital Equipment Corporation 
Ada Validation Facility: National Bureau of Standards 
Ada Compiler Validation Capability Version: 1.9 

Base Configuration: 

Compiler: VAX Ada Version 1.5 

Host Configuration: 

VAX 8800 (under VAX/VMS, Version 4.7) 

Target Configuration: 

VAX 8800 (under VAX/VMS, Version 4.7) 

VAXstation II (under MicrcVMS, Version 4.7) 
MicroVAX II (under VAXELN Toolkit, Version 3.0 
in combination with VAXELN Ada, Version 1.2) 


Derived Compiler Registration: 

Compiler: VAX Ada Version 1.5 

Host Configuration: 

All members of the VAX family: 

MicroVAX I 
VAXstation I 
MicroVAX II 
VAXstation II 
VAXstation 2000 

(all under MicroVMS, Version 4.7) 

MicroVAX 3500 
MicroVAX 3600 
VAXserver 3500 
VAXserver 3600 
VAXserver 3602 , 

VAXstation 3200 
VAXstation 3500 

(all under VAX/VMS, Version 4.7A) 

VAX-11/730 
VAX-11/750 
VAX-11/780 
VAX-11/782 
VAX-11/785 


2 





VAX 8200 
VAX 8250 
VAX 8300 
VAX 8350 
VAX 8500 
VAX 8530 
VAX 8550 
VAX 8600 
VAX 8650 
VAX 8700 

VAX 8800 (base configuration) 

(all under VAX/VMS, Version 4.7) 

Target Configuration: 

Same as Host; and the following VAXELN configurations 

MicroVAX I 
MicroVAX II 
rtVAX 1000 

KA620 (rtVAX 1000 processor board) 

MicroVAX 3500 
MicroVAX 3600 
VAX-11/730 
VAX-11/750 
VAX 8500 
VAX 8530 
VAX 8550 
VAX 8700 
VAX 8800 

(all under VAXELN Toolkit, Version 3.0 in 
combination with VAXELN Ada, Version 1.2) 


All of the processors listed above, including MicroVAX, VAXstatiori'; 
and VAXserver systems, are members of the VAX family. The VAX 
family includes multiple hardware/scftware implementations of the 
same instruction set architecture. All processors of the VAX family 
together with the VMS or MicroVMS operating system provide an 
identical user mode instruction set execution environment and need 
not be distinguished for purposes of validation. Similarly, all VAX 
family processors supported as VAXELN Toolkit targets provide an 
identical user mode instruction set execution environment. 

i 

The identical VAX Ada compiler is used on all hosts, and the 
compiler has no knowledge of the particular VAX model on which it is 
being executed. Further, the compiler generates identical code for 
all targets. Thus, the code generated on any VAX host can be 
executed without modification on any of the VAX targets listed 
above. 


3 






All of the configurations listed under the derived compiler 
registration section above are equivalent to the base configuration? 
That is, all applicable ACVC Version 1.9 tests could be correctly 
compiled and executed on any of the configurations listed. 


14 September 1987 


william JJ Heffl^er 

Vice President, System Software Group 




APPENDIX B 


* 


APPENDIX F OF THE Ada STANDARD 


The only allowed implementation dependencies correspond to 
implementation-dependent pragmas, to certain machine-dependent 
conventions as mentioned in chapter 13 of MIL-STD-1815A, and to certain 
allowed restrictions on representation clauses. The implementation- 
dependent characteristics of VAX Ada, Version l.S, are described in the 
following sections which discuss topics in Appendix F of the Ada 
Language Reference Manual (ANSI/MIL-STD-1815A).. Implementation- 
specific portions of the package STANDARD are also included in this 
appendix. 


package STANDARD is 


type INTEGER is range -2147483648 .. 2147483647; 
type SHORT_INTEGER is range -32768 .. 32767 ; 

type FLOAT is digits 6 range; 
type LONG_FLOAT is digits 15; 
type LONG_LONG_FLOAT is 33 digits; 

type DURATION is delta 1.0E-4 range -131072.0 .. 131071.9999; 


end STANDARD; 




APPENDIX.B 

APPENDIX F OF THE ADA'STANDARD 


The only allowed implementation dependencies correspond to 
implementation-dependent pragmas, to certain machine-dependent 
conventions as mentioned in chapter 13 of ANSI/MIL-57D-1815A-1983, 
and to certain allowed restrictions on representation classes. The 
implementation-dependent characteristics are described in the 
following sections which discuss topics one through eight as stated 
in Appendix F of the Ada Language Reference manual 
(ANSI/MIL-STD-1815A). Two other sections, package STANDARD and file 
naming conventions, are also included in this appendix. 

Portions of this section refer to the following attachments: 

1. Attachment 1 - Implementation-Dependent Pragmas 

2. Attachment 2 - VAX Ada Appendix F 


(1) Implementation-Dependent Pragmas 
See Attachment 1. 


(2) Implementation-Dependent Attributes 


Name 

Tvoe 




P'AST_ENTRY 

The value of this attribute 
SYSTEM. AST_HANDLZ?.. 

is 

of 

type 

P' BIT 

The value of this attribute 
universal_integer. 

is 

of 

type 

P'MACHINE_SIZE 

The value of this attribute 
universal_integer. 

is 

of 

type 


E-l 





* - I - V 

— ^ A r» •— ~ 

r w r c «•■w*w/v 



P' NULL__?ARAMETER 

The value of this attribute 
P. 

is 

of type 

P' TYPE__CLASS 

The value of this attribute 
SYSTEM.TYPE CLASS. 

is 

of type 


(3) Package SYSTEM 

See Attachment 2, Section F.3. 


(4) Representation Clause Restrictions 
See Attachment 2 , Section F.4. 


(5) Conventions 

See Attachment 2 , Section F.5. 


(6) Address Clauses 

See Attachment 2 , Section F.6. 


(7) Unchecked Conversions 

VAX Ada supports the generic function UNCHECKED_CONVERSION 
with the 'following restrictions on the class of types 
involved: 

1. The actual subtype corresponding to the formal type^ 

TARGET must not be an unconstrained array type. 

2. The actual subtype coresponding to the formal type 

TARGET must not be an unconstrained type with 
discriminants. 


(S) Input-Output Packages 

SEQUENTIAL_IO Package 

SEQUENTIAL 10 can be instantiated with any file 
type, including an unconstrained array type or an 
unconstrained record type. However, input-output 
for access types is erroneous. 


B-2 




APPENDIX F CF TR— Aw A STANDARD 


VAX Ada provides full support for SEQUENTIAL_IO, 

with the following restrictions and clarifications: 

1. VAX Ada supports modes IN_FILE and OU?_FILE for 
sequential input-output. - However, VAX Ada does 

„ not allow the creation of a file of mode 
IN_FILE. 

2. More than one internal file can be associated 
with the same external file. However, with 
default FORM strings, this is only allowed when 
all internal files have mode IN_FIL£ (multiple 
readers). If one or more internal files have 
mode OUT_FILE (mixed readers and writers or 
multiple writers), then sharing can only be 
achieved using FORM strings. 

3. VAX Ada supports deletion of an external file 
which is associated with more than one internal 
file. In this case, the external file becomes 
immediately unavailable for any new 
associations, but the current associations are 
not affected; the external file is actually 
deleted after the last association has been 
broken. 

4. VAX Ada allows resetting of shared files, but an 

implementation restriction does not allow the 
mode of a file to be changed from IN_FILE to 
OC7T_FIL£ (an amplification of accessing 

privileges while the external file is being 
accessed). 


DIR£CT_IO Package 

type CNT is range 0 .. 2147483647; 

TEXT_IO Package 

type CNT is range 0.. 2147483647; 

subtype FIELD is INTEGER rar.ce G .. 214748364/; 

LCW_LEVEL_IO 

Low-level input-output is not provided. 


I 

1 


B-3 



(9) Package STANDARD 

type INTEGER is range -2147483648 .. 214748.3647; 
type SHORT INTEGER is range -32763 .. 32767; 
type SHORT~SHORT INTEGER Is range -128 . . 127; 

— type LONG_INT£GER is not supported 

type FLOAT is digits 6; 

type LONG_FLOAT is digits 15; 

type LONG~LONG_FLOAT is digits 33; 

— type SHORT_FLOAT is not supported 

type DURATION is delta 1.0E-4 

range -131072.-0 .. .131071.9999; 


(10) File Names 

File names follow the conventions and restrictions of the 
target operating system. 








Attachment 1 


Predefined Language Pragmas 


This annex defines the pragmas LIST, PAGE, and OPTIMIZE, and 
summarizes the definitions given elsewhere of the remaining language- 
defined pragmas. 

The VAX Ada pragma TITLE is also defined in this annex. 


Pragma Meaning 

AST_ ENTRY Takes the simple name of a single 

entry as'the singe argument; at 
most one AST. ENTRY pragma 
is allowed for any given entry. 

This pragma must be used in 
combination with the AST_ ENTRY 
attribute, and is only allowed after 
the entry declaration and in the 
same task type specification or 
single task as the entry to which 
it applies. This pragma specifies 
that the given entrv may be used to 
handle a VAX/VMS asynchronous 
system trap (AST) resulting from a 
VAX/VMS system service call. The 
pragma does not affect normal use 
of the entry (see 9.12a;. 


Predefined language Pragmas i -1 





2 CONTROLLED 




3 ELABORATE 


Takes the simple name of an access 
type as the single argument. This 
pragma is only allowed immedi¬ 
ately within the declarative part or 
package specification that contains 
the declaration of the access type; 
the declaration must occur before 
the pragma. This pragma is not 
allowed for a derived type. This 
pragma specifies that automatic 
storage reclamation must not be. 
performed for objects designated 
by values of the access type, except 
upon leaving the innermost block 
statement, subprogram body, or 
task body that encloses the access 
type declaration, or after leaving 
the main program (see 4.8). 


Takes one or more simple names 
denoting library units as arguments. 
This pragma is only allowed imme¬ 
diately after the context clause of 
a compilation unit (before the sub¬ 
sequent library unit or secondary 
unit). Each argument must be the 
simple name of a library unit men¬ 
tioned by the context clause. This 
pragma specifies that the corre¬ 
sponding library unit body must be 
elaborated before the given compi¬ 
lation unit. If the given compilation 
unit is a subunit, the library unit 
body must be elaborated before the 
body of the ancestor library unit of 
the subunit (see 10.5). 


EXPORT. EXCEPTION Takes an internal name denoting an 

exception, and optionally takes an 
external designator (the name of a 
VAX/VMS Linker global symbol), a 
form (ADA or VMS), and a code (a 
static integer expression that is in¬ 
i' terpreted as a VAX condition code) 


1*2 Predefined Language Pragmas 



EXPORT. FUNCTION 


EXPORT. OBJECT 


u arguments. A code value must 
be specified when the form is VMS 
(the default if the form is not spec¬ 
ified). This pragma is only allowed 
at the place of a declarative item, 
and must apply »o an exception 
declared by an earlier declarative 
item of the same dedarative part 
or package specification: it is not 
allowed for an exception declared 
with a renaming declaration. This 
pragma permits an Ada excep¬ 
tion to be handled by programs 
written in other VAX languages 
(sec l3.9aJ.2). 

Takes an Internal name denoting a 
function, and optionally takes an 
external designator (the name of a 
VAX/VMS Linker global symbol), 
parameter types, and result type 
as arguments. This pragma is only 
allowed at the place of a declarative 
item, and must apply to a function 
declared by an earlier declarative 
item of the same declarative part 
or package specification. In the 
case of a function declared as a 
compilation unit, the pragma is 
only allowed after the function dec¬ 
laration and before any subsequent 
compilation unit. This pragma is 
not allowed for a function declared 
with a renaming declaration, and 
is not allowed for a generic func¬ 
tion (it may be given for a generic 
instantiation). This pragma permits 
an Ada function to be called from 
a program written in another VAX 
language (sec I3.9a.l.4). 

Takes an internal name denoting 
an object, and optionally takes an 
external designator (the name of a 
VAX/VMS Linker global symbol) 

> and size designator (a VAX/VMS 



Preoettneo Language Pragmas i -3 





Linker global symbol whose value 
is the size in bvtes of the exported 
object) as arguments. This pragma 
, is only allowed at the place of a 

declarative item at the outermost 
level of a library package speci¬ 
fication or body, and must apply 
to a variable declared by an ear* 
tier declarative item of the same 
package specification or body; 
the variable must be of a type or 
subtype that has a constant size 
at compile time. This pragma is 
not allowed for objects declared 
with a renaming declaration, and 
is not allowed in a genetic unit. 

This pragma permits an Ada ob¬ 
ject to be referred to by a routine 
written in another VAX language 
(sec 13.9a.2.2). 

EXPORT. PROCEDURE Takes an internal name denoting 

a procedure, and optionally takes 
an external designator (the name of 
a VAX/VMS Linker global symbol) 
and parameter types as arguments. 
This pragma is only allowed at the 
place of a declarative hem, and 
must apply to a procedure declared 
by an earlier declarative item of the 
same declarative part or package 
specification. In me case of a pro¬ 
cedure declared as a compilation 
unit, the pragma is only allowed 
after die procedure declaration and 
before any subsequent compilation 
unit. This pragma is not allowed 
for a procedure declared with a 
renaming declaration, and is not 
allowed for a generic procedure (it 
may be given for a generic instanti¬ 
ation). This pragma permits an Ada 
routine to be called from a program 


1 -a Predefined Language Pragmas 







written in another VAX language 
(see I3.9a.l.4). 

EXPORT. VALUED. PROCEDURE Takes an internal name denoting 
» a procedure, and optionally takes 

an external designator (the name of 
a VAX/VMS Linker global symbol) 
and parameter types as arguments. 
This pragma is only allowed at the 
place of a declarative item, and 
must apply to a procedure declared 
by an earlier declarative item of the 
same declarative part or package 
specification. In the case of a pro¬ 
cedure declared as a compilation 
unit, the pragma is only allowed 
after the procedure declaration and 
before any subsequent compilation 
unit. The first (or only) parameter 
of theprocedurc must be of mode 
out. This pragma is not allowed 
for a procedure declared with a 
renaming declaration and is not 
allowed for a generic procedure (it 
may be given for a generic instan¬ 
tiation). This pragma permits an 
Ada procedure to behave as a func¬ 
tion that both returns a value and 
causes side effects on its parame¬ 
ters when it is called from a routine 
written in another VAX language 
(see 13.9a.l.4). 


IMPORT.EXCEPTION Takes an internal name denoting 

an exception, and optionally takes 
an external designator (the name 
of a VAX/VMS Linker global sym¬ 
bol), a form (ADA or VMS), and 
a code (a static integer expres¬ 
sion that is interpreted as a VAX 
condition code) as arguments. A 
code value is allowed only when 
i the form is VMS (the default if the 
' form is not specified). This pragma 


Predefined Language Pragmas i -5 







IMPORT. FUNCTION 


IMPORT. OBJECT 


is only allowed at the place of a 
declarative item, and must apply 
to an exception declared by an 
earlier declarative item of the same 
declarative part or package spec¬ 
ification; it is not allowed for an 
exception declared with a renaming 
declaration. This pragma permits a 
non-Ada exception (most notably, 
a VAX condition) to be handled by 
an Ada program (see 13.9a.3.1). 

Takes an internal name denoting a 
function, and optionally takes an 
external designator (the name of a 
VAX/VMS Linker global symbol), 
parameter types, result type, and 
m echa nism'as arguments. Pragma 
INTERFACE must be used with this 
pragma (see 13.9). This pragma 
is only allowed at the place of a 
declarative Hem, and must apply 
to a function declared by an earlier 
declarative item of the same declar¬ 
ative part or package specification. 
In the case of a function declared 
as a compilation unit, the pragma is 
only allowed after the function dec¬ 
laration and before any subsequent 
compilation unit. This pragma is al¬ 
lowed for a function declared with 
a renaming declaration; it is not 
allowed for a generic function or a 
generic function instantiation. This 
pragma permits a non-Ada rou¬ 
tine to be used as an Ada function 
(see 13.9a.l.l). 

Takes an internal name denoting 
an object, and optionally takes an 
external designator (the name of a 
VAX/VMS Linker global symbol) 
and size (a VAX, 'VMS Linker global 
symbol whose value is the size in 
; bytes of the imported object) as 
arguments. This pragma is only 


1*6 Predefined Language Pragmas 




p 



IMPORT. PROCEDURE 


IMPORT. VALUED. PROCEDURE 


allowed at the place of a declara¬ 
tive item at the outermost level of 
a library package specification or 
body, and must apply to a variable 
declared by an earlier declarative 
item of the same package specifi¬ 
cation or body: the variable must 
be of a type or subtype that has a 
constant size at compile time. This 
pragma is not allowed for objects 
declared with a renaming declara¬ 
tion, and is not allowed in a generic 
unit. This pragma permits storage 
declared in a non-Ada routine to 
be referred to by an Ada program 
(see 13.9a.2.1). 

Takes an internal name denoting 
a procedure, and optionally takes 
an external designator (the name of 
a VAX/VMS Linker global symbol) 
parameter types, and m echan ism 
as arguments. Pragma INTERFACE 
must be used with this pragma 
(see 13.9). This pragma is only 
allowed at the place of a declar¬ 
ative item, and must apply to a 
procedure declared by an earlier 
declarative item of the same declar¬ 
ative part or package specification. 
In the case of a procedure declared 
as a compilation unit, the pragma 
is only allowed after the proce¬ 
dure declaration and before any 
subsequent compilation unit. This 
pragma is allowed for a procedure 
declared with a renaming declara¬ 
tion; it is not allowed for a generic 
procedure or a generic procedure 
instantiation. This pragma permits 
a non-Ada routine to be used as an 
Ada procedure (see 13.9a.1.1). 

Takes an internal name denoting a 
procedure, and optionally takes an 
external designator (the name of a 


Predefined Language Pragmas 1 -7 





4 INLINE 


5 INTERFACE 


VAX/VMS Linker global symbol), 
parameter types, and mechanism 
as arguments. Pragma INTERFACE 
must be used with this pragma 
(see 13.9). This pragma is only 
allowed at the place of a declar¬ 
ative item, and must apply to a 
procedure declared by an earlier 
declarative item of the same declar¬ 
ative part or package specification. 
In the case of a procedure declared 
as a compilation unit, the pragma 
is only allowed after the procedure 
declaration and before any subse¬ 
quent compilation unit. The first 
(or only) parameter of the proce¬ 
dure must be of mode out. This 
pragma is allowed for a procedure 
declared with a renaming declara¬ 
tion; it is not allowed for a generic 
procedure. This pragma permits 
a non-Ada routine that returns a 
value and causes side effects on its 
parameters to be used as an Ada 
procedure (see I3.9a.l.l). 

Takes one or more names as ar¬ 
guments; each name is either the 
name of a subprogram or the name 
of a generic subprogram. This 
pragma is only allowed at the place 
of a declarative item in a declarative 
part or package specification, or af¬ 
ter a library unit in a compilation, 
but before any subsequent compi¬ 
lation unit. This pragma specifies 
that the subprogram bodies should 
be expanded inline at each call 
whenever possible; in the case of 
a generic subprogram, the pragma 
applies to calls of its instantiations 
(see 6.3.2). 

. Takes a language name and a sub¬ 
program name as arguments. This 


1*8 Predefined language Pragmas 



LIST 


pragma ia allowed at the place of a 
declarative item, and must apply in 
this case to a subprogram declared 
by an earlier declarative item of the 
same declarative part or package 
specification. This pragma is also 
allowed for a library unit; in this 
case the pragma must appear after 
the subprogram declaration, and 
before any subsequent compila¬ 
tion unit. This pragma specifies 
the other language (and thereby 
the calling conventions) and in¬ 
forms the compiler that an object 
module will be supplied for the 
corresponding subprogram (see 
13.9). 


In VAX Ada. pragma INTERFACE 
is required in combination with 
pragmas IMPORT. FUNCTION, 
IMPORT. PROCEDURE, and 
IMPORT. VALUED. PROCEDURE 
(see 13.9a.l). 

Takes one of the identifiers ON 
or OFF as the single argument. 
This pragma is allowed anywhere 
a pragma is allowed. It specifies 
that listing of the compilation is to 
be continued or suspended until 
a UST pragma with the opposite 
argument is given within the same 
compilation. The pragma itself 
is always listed if the compiler is 
producing a listing. 


LONG. FLOAT 


Takes either D_ FLOAT or G_ 
FLOAT as the single argument. 
The default is G.FLOAT. This 
pragma is only allowed at the start 
of a compilation, before the first 
compilation unit (if any) of the 


Predefined Language Pragmas 1 -9 






compilation. It specifies the choice 
of representation to be used for the 
predefined type LONG. FLOAT 
in package STANDARD and for 
floating point type declarations with 
digits specified in the range 7..15 
(see 3.5.7a). 


MAIN. STORAGE .Takes one’or two nonnegative 

static simple expressions of some 
integer type as arguments. This 
pragma is only allowed in the 
outermost declarative part of a 
library subprogram; at most one 
such pragma is allowed in a library 
subprogram. It has an effect only 
when the subprogram to which it 
applies is used as a main program. 
This pragma causes a fixed-size 
stack to be created for a main task 
(the task associated with a main 
program), and determines the 
number of storage units (bytes) to 
be allocated for the suck working 
storage ere a or guard pages or 
both. The value specified for either 
or both the working storage area 
and guard pages is rounded up 
to an integral number of pages. 

A value of zero for the working 
storage area results in the use of 
a default size; a value of zero for 
the guard pages results in no guard 
storage. A negative value for either 
working storage or guard pages 
causes the pragma to be ignored 
(see 13.2b). 

7 MEMORY.SIZE Takes a numeric literal as the 

single argument. This pragma 
is only allowed at the start of 
; a compilation, before the first 
compilation unit (if any) of the 


-10 Predefined Language Pragmas 






compilation. The effect of this 
pragma is to use the value of the 
specified numeric literal for the 
* definition of the named number 

MEMORY. SIZE (see 13.7). 

8 OPTIMIZE Takes one of the identifiers TIME 

or SPACE as the single argument. 
This pragma is only allowed within 
a declarative part and it applies 
to the block or body enclosing 
the declarative part. It specifies 
whether time or space is the pri- 
maty optimization criterion. 


In VAX Ada, this pragma is only 
allowed immediately within a 
declarative part of a body declara¬ 
tion. 

9 PACK Takes the simple name of a record 

or array type as the single argu¬ 
ment. The allowed positions for 
this pragma, and the restrictions on 
the named type, are governed by 
the same rules as for a representa¬ 
tion clause. The pragma specifies 
that storage minimization should be 
the main criterion when selecting 
the representation of the given type 
(see 13.1). 

10 PAGE This pragma has no argument. 

and is allowed anywhere a pragma 
is allowed. It specifies that the 
program text which follows the 
pragma should start on a new 
page (if the compiler is currently 
producing a listing). 

11 PRIORITY Takes a static expression of the pre¬ 

defined integer subtype PRIORITY 
as the single' argument. This 
pragma is only allowed within 
‘ the specification of a task unit or 


Predefined Language Pragmas i -i i 





12 


» 


PSECT. OBJECT 


SHARED 


immediately within the outermost 
declarative part of a main program. 
It specifies the priority of the task 
(or tasks of the task type) or the 
priority of the main program (see 


Takes an internal name denoting 
an object, and optionally takes an 
external designator (the name of 
a program section) and a size (a 
VAX/VMS Linker global symbol 
whose value is interpreted as 
the size in bytes of the exported 
/imported object) as arguments. 
This pragma is only allowed at the 
place of a declarative item at the 
outermost level of a library package 
specification or body, ana must 
apply to a variable declared by an 
earlier declarative item of the same 
package specification or body; 
the variable must be of a type or 
subtype that has a constant size 
at compile time. This pragma is 
not allowed for an object declared 
with a renaming declaration, and is 
not allowed in a generic unit. This 
pragma enables me shared use of 
objects that are stored in overlaid 
program sections (see 13.9a.2.3). 

Takes the simple name of a vari¬ 
able as the single argument. This 
pragma is allowed only for a vari¬ 
able declared by an object decla¬ 
ration and whose type is a scalar 
or access type; thevariable decla¬ 
ration and the pragma must both 
occur (in this order) immediately 
within the same declarative part or 
package specification. This pragma 
specifies that every read or update 


< 


( 


•12 Predefines Language Pragmas 






of the variable is a synchroniza¬ 
tion point for that variable. An 
implementation must restrict the 
objects for which this pragma is 
allowed to objects for which each of 
direct reading and direct updating 
is implemented as an indivisible 
operation (see 9.11). 

VAX Ada does not support pragma 
SHARED (see VOLATILE). 

Takes a numeric literal as the 
single argument. This pragma 
Is only allowed at the start of 
a compilation, before the first 
compilation unit (if any) of the 
compilation. The effect of this 
pragma is to use the value of the 
specified numeric literal for the 
definition of the named number 
STORAGE. UNIT (see 13.7). 

In VAX Ada. the only argument 
allowed for this pragma is eight (8). 

Takes as arguments the identifier 
of a check and optionally also 
the name of either an obfect. a 
type or subtype, a subprogram, a 
task unit, or a generic unit. This 
pragma is only allowed either im¬ 
mediately within a declarative part 
or immediately within a package 
specification. In the latter case, the 
only allowed form is with a name 
that denotes an entity (or several 
overloaded subprograms) declared 
immediately within the package 
specification. The permission to 
omit the given check extends from 
the place of the pragma to the end 
of the declarative region associated 

Predefined Language Pragmas 1-13 





with the innermost enclosing block 
statement or program unit. For a 
pragma given in a package specifi¬ 
cation, the permission extends to 
the end of the scope of the named 
entity. 

If the pragma includes a name, the 
permission to omit the given check 
is further restricted: it is given only 
for operations on the named object 
or on all objects of the base type 
of a named type or subtype: tor 
calls of a named subprogram; for 
activations of tasks of the named 
task type; or ter instantiations of 
the given generic unit (see 11.7). 

VAX Ada docs not support pragma 
SUPPRESS (see SUPPRESS. ALL). 


SUPPRESS. ALL 


This pragma has no argument 
and is only allowed following a 
compilation unit. This pragma 
specifies-that all run-time checks in 
the unit are suppressed (see 11.7). 


t« SYSTEM. NAME Takes an enumeration literal as 

the single argument. This pragma 
is only allowed at the start of 
a compilation, before the first 
compilation unit (if any) of the 
compilation. The effect of this 
pragma is to use the enumeration 
literal with the specified identifier 
for the definition of the constant 
SYSTEM. NAME. This pragma 
is only allowed if the specified 
identifier corresponds to one of the 
literals of the type NAME declared 
in the package SYSTEM (see 13.7). 

I 


1*14 Predefined Language Pragmas 





TASK. STORAGE 


TIME. SLICE 


Takes the simple name of a task 
type and a static expression of 
some integer type as arguments. 
This pragma is allowed anywhere 
that a task storage specification is 
allowed; that is, the declaration of 
the task type to which die pragma 
applies and the pragma must both 
occur 0" this order) immediately 
within the same declarative part, 
package specification, or task 
specification. The effect of this 
pragma Is to use the value of 
the expression as the number of 
storage units (bytes) to be allocated 
as guard storage. The value is 
rounded up to an integral number 
of pages: a value of zero results in 
no guard storage; a negative value 
causes the pragma to be ignored 
(see 13.2a). 


Takes a static expression of 
the predefined ffaced point 
type DURATION fin package 
STANDARD) as the single argu¬ 
ment This pragma is only allowed 
in the outermost declarative part 
of a library subprogram, and at 
most one such pragma is allowed 
in a library subprogram. It has an 
effect only when the subprogram to 
which it applies is used as a main 
program. This pragma specifies the 
nominal amount of elapsed time 
permitted for the execution of a 
task when other tasks of the same 
priority are also eligible for exe¬ 
cution. A positive, nonzero value 
of the static expression enables 
round-robin scheduling for all tasks 
i in the subprogram; a negative or 
zero value disables it (see 9.8a). 


Prtoeflneo isnguage Pragmas i-is 


TITLE 


VOLATILE 


Takes a title or a subtitle string, or 
both, in either order, as arguments. 
Pragma TITLE has the form: 

ir|- mu 

(.itUtH'OUNl): 

ttms »»1 •utH.Utwtl 
t (ssariru •») •trtaa.ut«r«i 

This pragma is allowed anywhere a 
pragma is allowed: the given strings 
supersedes the default title and/or 
subtitle portions of a compilation 
listing. 


Takes the simple name of a vari¬ 
able as the single argument. This 
pragma is only allowed for a vari¬ 
able declared by an object declara¬ 
tion. The variable declaration and 
the pragma must both occur (in this 
order) immediately within the same 
declarative part or package speci¬ 
fication. The pragma must appear 
before any occurrence of the name 
of the variable other than in an ad¬ 
dress clause or in one of the VAX 
Ada pragmas IMPORT. OBJECT, 
EXPORT.OBJECT, or PSECT. 
OBJECT. The variable cannot be 
declared by a renaming declaration. 
The VOLATILE pragma specifies 
that the variable may be modified 
asynchronously. This pragma in¬ 
structs the compiler to obtain the 
value of a variable from memory 
each time it is used (see 9.11). 


i-i» Predefined Language Pragmas 


Attachment 2 


Implementation-Dependent 

Characteristics 


NOT! 

This appendix ia not part oI the standard definition of the 
Ada programming language. 

This appendix aununarixea the implementation-dependent characteris¬ 
tics ol VAX Ada by 

• listing the VAX Ada pragmas and attributes. 

• Giving the specification of the package SYSTEM. 

• Presenting the restrictions on repre s e n tation clauses and unchecked 
type conversions. 

• Giving die conventions (or names denoting implementation- 
dependent components in record representation clauses. 

• Giving the i n ter p ret a tion of expr e ss ion s in address clauses. 

• Presenting the implementation-dependent characteristics of die 
input-output packages. 

• Presenting other implementation-dependent characteristics. 


Imptementanon-Oepenoent Characteristics 2-1 




F.1 Implamantatlon-Dapandant Pragmas 

VAX Ada provides the following primes, which ere defined elsewhere 
in the text, hi addition. VAX Ada restricts the predefined language 
pragmas INLINE and INTERFACE, and provides alternatives to me 
pragmas SHARED and SUPPRESS (VOLATILE and SUPPRESS. ALL)- 
See Annex B for a descriptive pragma summary. 

• . AST.ENTRY (see 9.12a) 

• EXPORT.EXCEPTION (see 13.9aJ.2) 

• EXPORT.FUNCTION (see I3.9a.l.4) 

• EXPORT.OBJECT (see 13.9a.2.2) 

• EXPORT.PROCEDURE (see 13.9a.l.4) 

• EXPORT.VALUED.PROCEDURE (see I3.9a.l.4) 

• IMPORT.EXCEPTION (see 13.9a.3.1) 

• IMPORT.FUNCTION (see 13.9a.l.l) 

• IMPORT.OBJECT (see 13.9a.2.1) 

« IMPORT.PROCEDURE (see 13.9a.l.l) 

• IMPORT.VALUED. PROCEDURE (see 13.9a. 1.1) 

• LONG. FLOAT (sec 3.5.7a) 

• MAIN. STORAGE (see 13.2b) 

• PSECT. OBJECT (sec l3.9a.23) 

• SUPPRESS. ALL (sec 11.7) 

• TASK. STORAGE (see 13.2a) 

• TIME.SLICE (see 9.8a) 

• TITLE (see B) 

• VOLATILE (see 9.11) 


2-2 tmptemematton-Otpendsm Characteristics 








8 


F.2 Implementation-Dependent Attributes 

VAX Ada provides the following attributes, which are defined else¬ 
where in the teat. See Annex A for a de scriptive attribute summary. 

• AST.ENTRY (sec f.l2a) 

• BIT (sec 13.7.2) 

• MACHINE. SIZE (see 13.7.2) 

• NULL.PARAMETER (see 13.9a.l.3) 

• TYPE. CLASS (see 13.7a.2) 


F.3 Specification of the Package System 


» 7f turn U OTU.WS. VUSUI): 

srstnrjuM 

NHtUt 

urn :• ru.se 

•mm.Beit 

mum 

• is 

mnr.na 

IMIUW 

• >*01-1; 

MX.1ST 

mmuii 

• 3*01-1; 

MS. 1ST 

MMNM 

• -(3*01); 

mx. Siam 

MMUlt 

• 33; 

MX.MSIISSA 

wm*H 

• 31; 

riSX.DC.tl 

MMtMt 

• 3.D**(-31); 

TICS 

mrtut 

• lS.0**(-3) ; 


miff* nuoun ti nma m«* s .. is; 


— IMTMi «JJI 

tjf MUIB li plntt; 


ADCMSS.au : MWI U90US; 


tlMUW 


(lin : 


1; mot : 

xxtxen) man uoaus 

IlMttW 


(UR i 

mat 

i; meat : 

UBUMS) man 

uoons 

fuiUH 

••• 

(UR : 

m*|« 

1: men ; 

UUUS) ratan 

omen 

funiM 

*•* 

(UR : 

mm» 

i; men 

nrtXCXB) ratan 

uoano 

iMttlN 

••• 

(UR. 

BIOT 

xseaxss) 

man sosuua 



tlMUW 


(UR. 

Stan 

mutt) 

man boouu 




*<• 

(UR. 

neat 

upturn 

man boouu 



(UltlH 


(UR. 

meat 

umns) 

man IOOUU 



tMHIW 

*>" 

(UR. 

meat 

XDOUSS) 

man boouu 



fMttlM 


(UR. 

meat 

usans) 

man boouu 






Implementation-Dependent Characteristics 2-3 














•• M* ttot t mm UOUH it a yriaata tff* 

— UM (iMtilM h» M 4 •/■• in Utn4y i«UUUi u4 
M tan u t* a^UiUljr Mtata 


pMrti 

Iff* tlMR ta 

tiMtin mca.niM.imcn a : Maun) ntm ruost; 


lyft MHtt la prtwui 

HMtam wui.7i.iMiai a : muss, t : nut?). 

kyya TTPt,CUM la (rm.am.BNHBUTXM. 

nR.cua.nnta. 
rmjajasjimjnm , 
rrps.euM.ruiTUM.Mun. 
npc.euM.mjT. 
TTPt.eUM.UC8U. 

npt.euM.utns. 

nPC.euM.tiM. 

TTPt.CUM.4MUM); 

~ til 44a UmI1i| yalat ImUmUmu far 111 VAX 
•• tarlMn tlaaklaf MM 4ata tppaa 

tppa D.FU4T la impJtmtnittion, dtjlntd; 
kyya r.rtOlT la tmjt/tmtnititttK dtfirud; 
kypa e.ruiT la xitpianMnlaltan. itfintd-, 
kypa l.ruit la impi«nMnla<ian.4</ln«dl'. 


— 1ST kaa41ar tppa 

MM 1STJUSDUS la 1WM Mima; 
W.lST.Bunm ; aaaataa* lST.SlBMXSs 


*• laa-Ma maftlii 

808.401. DUOS : amaptlaa; 

-- MI kar*aara*arlaata4 tyyaa aa4 ftactlaaa 

%TM 0IT.4U4T la array (union rup o) af I0QLX48; 
prana PICKIIT.MUT); 


aaktyya IIT.4M4T.S la STT.4U4T 

(0 .. 

T) 

aaktyya SlT.4SUT.lf la S1T.UUT 

(0 .. 

IS) 

aaktyya SlT.4MUT.ia la I1T.4U4T 

(0 .. 

ai) 

aaktyya S1T.UUT.S4 la S1T.UUT 

(0 .. 

43) 

try* OOTICntD.BTTt la rup 0 .. 

ass; 



tar BSSIQStD.ITTC'SIZt aaa •; 


2-4 Impitmtntation-Oapanotnt Characteristics 







tuuiH (urr : oMiovn.im) mm oMtoms.tm 

t «mum *u4* am, non ; oMiexo.mi) r.««n aMtam.ira 
*«mtM ••r* am. Man •. woiens.im) man umichb.itt* 
immim *w am. axon : uwicxo.oTTt) man oMicns.om 


(untM TB.ontoRi8.om a : iit.uxxt.i) mm mioa.im; 
iimum tun.uui.i a : wiciDjrii) mm azr.ujur.t; 

BMians.iTTt.mtT w imr (xntaot ruyt «») h onions .im; 


% r9 * omicbo.voob u rup a .. nui 

far BMIHD.BOU'STZX ••• 10: 

imttM •m*. am : miens.*ras) mm miens.veu 

tuiitM •m 4« am. oxon .• mians.teu) mm mieno.rau 
fuoiM am. wen : miens.*ou) mm mioatB.voxo 

m«im »w am, urn : omioro.vou) mm mions.nu 


tuitlM TO.miOXO.IOtS (X : lIT_XXXAT.lt) ntm OMICXO.VOU; 
ImltM TO.XIt.AXXAT.lt (X : mtOHCS.mS) mm IIT.UXtT.lt; 

tyya miOHB.VOM.XUUT It array (IVTCCIX rup «>) .f OMIOnS.mU; 


tyya OM1CH3.L0RCTOS It mp XIX. I«T .. KAX.IXT; 
tar mianS.UMVQU'SXZS U< »; 

tutUM •»«■ am : mxcxn.toxcvou) mm mtans.t.nnsu 

ftuiiN »«u* am. non : Bxsians.LOMvou) mm aMiean.t.esevMo 

faaattaa *ar* (Lin, oxen : OBOIOXO.LOXOVOIO) mm BMrsao.Lexeysao 

faaattaa *«a»* (LOT. Mon : OMIOXO.LOXCVOXS) ratart anXOHS.LOMraS 

faMUat TO.OmieXD.LCVeVOU (X : MT.XUUr.33) 

man onianD.Loanou; 

fatattaa T0jn.XUUT.33 U : OWiexO.LOXCVOXS) man 3XT.XUXT.33: 


tyya OMTQnB.LORenilO.XUUT la 

array (IRTZCI3 rup «») at 0MI8BE»_U»CV0t&; 


»T»« OnXORD.OOXBVOM la mart 
LQ : OMtORD.LOROniO; 


far OMieHO.OOXOVOM'Sm aaa 04; 


faaatAaa *aa«* (LOT ; omcXXS.QOXOTOU) 

faaattaa »aat* (LOT. XI03T : OMtCRD.OOXOVOM) 
faaattaa *ar* (LOT. KICRT ; OMICnS.QOXDnU) 
faaaalaa *»r* (LOT. MORI : OMICXO.OUiDVOM) 


mart omxens.qotDtoxB 
ratara UWICtJEO.qotBTOtS 
ratara UOTCItO.qotOTCAB 
ratara OXCICKU.QUXOIOU 


faaattaa TO.OSSICnD.QOXDVOXO (X : BIT.tRXXT.04) 
ratara ORSXCOEO.qOtDOOU; 

faaattaa T0.BIT.XUUT.04 (X : ORSTeno.OOlOVOKO) ratara IIT.XUUT.t4; 


Implomontation-OoDonoont Characteristics 2*5 






typi imSI0mB.80iDW«B.*WUT ta 

array (IXTtsn ruga <>) ■( UVSICVU.g’JiOlOU). 

Incttn T0.10SIE33 (I : URtCQ) ratara 100USS: 

(mini TO.UDUSS (X : TO3ISHXS.L0IICVQU) nun ADDRESS: 

(UrtlM TD.ADDRESS (X : umvcrta/.irUcfcr) ritm ADDRESS; 

(uctlM TO.WTtfltt (X : UtUSS) ntin irrtStl; 

luttiat 10.0031608.10161019 (X : ADDRESS) nun ORSI6RE8.UIR010RD; 

(mini To.umxens.Loiievau <x : utjiinin) nun miiaiD.LBMMW; 


— Cuvntlml iimi far italic aabtypaa if typo OSSXCRXD.LOIIGIORD 

atwn* orsxgred.x it oosiGRtt.toocm8 tup o i« i-i: 
mint onsioocD.a la msxons.Loiiovou ruga a .. an a-t; 

mini onaiam.3 u umsiched.loiicvoxd ruii o .. a«« a-t; 

aut^a oosxcmo.4 i« wsJcm»_io»c*eiu> ruga a .. an «-t; 

•ittna tmsioms.f la tmsteito.LaMcvou rup a .. aaa a-t; 

aaktypa tmsxcmo.a la tmsi6RED.t.ORGfou rup a .. an a-t; 

aaktypa tmsicmo.r la oosiams.LONGieko ruga a .. an r-i; 

aaktypa UHSICRED.a la ORStCRXD_t.0aGmD rug* 0 .. 3« a-1; 

aaktypa orsicred.i la 0HsicRO_t.0Rei0RD ruga a .. an e-i; 

aaktypa OHSICKED.IO la ORSICRD.LORGmO ruga o .. 3«l0-t; 

aiktn< oosiGKt9.ii la oosioon.ioocioRD raaga e .. ami-t: 

aaktypa OOSICIIED.13 la OflSICKD.LaRCVOU raaga 0 .. ania-l; 

aaktypa 00SIC0ED.13 la mniCOED.LOOCIORD ruga a .. an 13 - 1 : 

aaktypa 0KSIC0ED.14 la QRSXGOE9.L0RG10R9 ruga a .. an 14-1; 

aaktypa OOSIGOED.tS la tmsiGKD.LORGmD ruga a .. ams-l; 

aaktypa UXSICHID.16 la OOSICOD.LORCVOU raaga a .. anta-t; 

aiktna UHSIGOED.lT la 0081600.1.0081009 ruga a .. anlT-l; 

aaktypa ORSIC]«a.ll la OOSXCBD.tOOCIOOD ruga 0 .. ami- 1 ; 

aaktypa ORSXCRCO.XI la ORSXCOD.X.Oirenu ruga 0 .. anta-t; 

aaktypa 0RSICRE9.3O la OOSXGOO.IOOGIORD raaga 0 .. anjO-l; 

aaktypa 0DSIC8D.31 . Ok 'ICOD.IOKGIORD ruga 0 .. 3—31-1; 

aaktypa OOSICOO.33 la 00.1600.1.0061019 ruga 0 .. 3**33-t; 

aaktypa 0031800.33 la ORSICOD.LOOemD ruga 0 .. 3«3J-1; 

aaktypa ORSISHn.34 la 0KSX6RD.L0KG10RD ruga 0 .. 3n34-t; 

aaktypa OHS I CUED. 3* la ORSIGOD.LOOamO ruga 0 .. 3*<«-t; 

aaktypa UHSICHED.34 la OOSICOO.LONGiaRO ruga 0 .. 3a*3S-t; 

aaktypa 0RSXCHE0.37 la QOSXGRD.LONCmD ruga 0 .. 3»37-l; 

aaktypa UMSICHE0.38 la DHSXCRD.l.ORCiaRD ruga 0 .. 3a«3S-l; 

aaktypa OMStCtlEO.30 la miGRED.LOMGfOU ruga 0 .. 3n3S-t; 

aaktypa 0HSICHED.30 la tmSIGOD.lOKClOOD ruga 0 .. 3n30-l; 

aaktypa UHSIcmD.3l la UHSICOD.lOOGiaRD ruga 0 .. 3n3t-t; 

— Fanctian far obtaining glakal ayabol valaaa 

fanctloa INP03T.Vll.yE (SYMBOL : STRINC) raturn OllSICHEO.LOHGVORD; 


— VAX davlea aa4 pracaaa ragiatar aparatloaa 


2-6 imoiementation-Oepenoent Characteristics 








tlictlll READ.REOISTER (SOURCE : UltSIGNED.BTTE) rotor* UNSIGNED_STTE: 

ftattles READ.REGISTER (SOURCE : UNSIGNED.VORD) rtltn UNSICNED.VORD: 

REAOJtXGISTEl (SOURCE : UNSICNED.LONGVORO) rotor* UNSJGND.LONOVORD; 

•r«u4Mi VRITE.REOISTEMSOURCE : UNSIGNED.BYTE; 

TUCET : nt UNSIOHID.BTTE); 
wm(4iii vr:te_rec:sier(source . unsicned.vord; 

TARGET : UNSIGNED.VORD); 

praooAtro fRITE.AEGISTDUSOUACE : U38I0HED.LONGWORD; 

TARGET : **t UNSIONED.LON6VORO): 


fiMitu «n (reg.nunber : integer) rater* uhsigned.lonovord; 
frKKui NIP* (REG.NUNBER : INTEGER; 

SOURCE : UNSICNED.LONGVORD); 


VAX i»torlocked-1notrictloo procedoroo 

proeedere CLEAR.INTERLOCKS) (BIT : la elt BOOLEAN; 

OLD.VALUE : nt BOOLEAN); 

prictAui SET.INTERLOCKED (BIT : la BOOLEAN; 

OLD.VALUE ; oat BOOLEAN); 

typo ALIONES.SHOtT.INTEGER la 

rocarl 

VALUE : SHORT.INTEGER :• 0; 

eed record; 

far ALIGNED.SHORT.INTECER taa 

retard 

at mA 3; 
eaA retard; 

pratedaro ADD.INTERLOCKED (ADDEND : la SHORT.INTEGER: 

AUGEND : la aat ALICNED.SHORT.INTEGER; 
SICH : aat INTEGER); 


type INSQ.STATUS la (OE.NOT.FIRST. rAIL.NO.LOCE. OE.riRST); 
type RENO.STATUS la (OK.NOT.ENPTT. rAIL.NO.LOCE. 

OE.EKPTT, FAIl.VAS.EKPTT); 

procedure INSOHI (ITEM : la ADDRESS; 

HEADER : la ADDRESS; 

STATUS ; aat INSS.STATUS); 

procedure RENQHI (HEADER ; la AODRESS; 

ITEM ; aat ADDRESS; 

STATUS : eat RENO.STATUS); 


proeaAara IHSQTI (ITEM ; la ADDRESS; 

HEADER : la ADDRESS; 

STATUS ; eat IHSG.STATVS); 

procedure RENOTI (HEADER : la ADDRESS; 

ITEM : oat ADDRESS; 

STATUS : oat RENO.STATUS); 


Implementation-Dependent Characteristics 2-7 



(rinti 

-- Mat *ha«* 
•*4 SYSTEM; 


F.4 Restrictions on Representation Clauses 

The representation clauses allowed in VAX Ada are length, enumera¬ 
tion, record representation, and address clauses. 

In VAX Ada, a representation clause for a generic formal type or a 
type that depends on a generic formal type is not allowed. In addition, 
a representation clause for a composite type that has a component 
or subcomponent of a generic formal type or a type derived from a 
generic formal type is not allowed. 


F.5 Conventions for Implementation-Generated Names 
Denoting Implementation-Dependent Components in 
Record Representation Clauses 

VAX Ada does not allocate implementation-dependent components in 
records. 


F.6 Interpretation of Expressions Appearing in Address 
Clauses 

Expressions appearing in address clauses must be of the type 
ADDRESS defined in the package SYSTEM (see 13.7a.1 and F.3). 

In VAX Ada. values of type SYSTEM.ADDRESS are interpreted as 
integers in the range O..MAX_INT, and they refer to addresses in the 
user half of the VAX address space. 

VAX Ada allows address clauses for variables (see 13.5). 

VAX Ada does not support interrupts. 


2-8 Implementation-Dependent Characteristics 




F.7 Restrictions on Unchecked Type Conversions 

VAX Ads supports the generic function UNCHECKED,CONVERSION 
with the restrictions given in section 13.10.2. 


F.8 Implementation-Dependent Characteristics of 
Input-Output Packages 

The VAX Ada predefined packages and their operations are imple¬ 
mented using VAX Record Management Services (RMS) file orga¬ 
nizations and facilities. To give users the maximum benefit of the 
underlying VAX RMS input-output facilities, VAX Ada provides pack¬ 
ages in addition to the packages SEQUENTIAL. IO. DIRECT. IO, 
TEXT.IO, and IO. EXCEPTIONS, and VAX Ada accepts VAX RMS File 
Definition Language (FDL) statements in form strings. The following 
sections summarize the implementation-dependent characteristics of 
the VAX Ada input-output packages. The VAX Ada Run-Time Reference 
Manual discusses these characteristics in more detail. 


F.8.1 Additional VAX Ada Input-Output Packages 

In addition to the language-defined input-output packages (SEQUENTIAL. 
IO. DIRECT. IO. and TDCT.IO), VAX Ada provides the following 
input-output packages: 

• RELATIVE.IO (see 14.2a.3) 

• INDEXED.IO (see 14.2a.S) 

• SEQUENTIAL.MDCED.IO (see 14.2b.4) 

• DIRECT.MIXED.IO (see 14.2b.6) 

• RELATIVE.MIXED.IO (see 14.2b.8) 

• INDEXED.MIXED.IO (see 14.2b. 10) 

VAX Ada does not provide the package LOW.LEVEL.IO. 


Implementation-Dependent Characteristics 2-9 






F.8.2 Auxiliary Input-Output Exemptions 

VAX Ada defines the exceptions needed by the packages RELATIVE. 
10, INDEXED.IO. RELATIVE. MIXED. 10. and INDEXED. MIXED. 10 
in the package AUX. IO. EXCEPTIONS (see 14.5a). 


F.8.3 Interpratatlon of tha FORM Parameter 

The value of the FORM parameter for the OPEN and CREATE proce¬ 
dures of each input-output package may be a string whose value is in¬ 
terpreted as a sequence of statements of the VAX Record Management 
Services (RMS) File Definition Language (FDL), or it mav be a string 
whose value is interpreted as the name of an external fife containing 
FDL statements. 

The use of the FORM parameter is described for each input-output 
package in chapter 14. For information on the default FORM param¬ 
eters for each VAX Ada input-output package and for information on 
using the FORM parameter to specify external file attributes, see the 
VAX Ada Run-Time Reference Manual. For information on FDL. see the 
Guide to VAX/VMS File Applications and the VAX/VMS File Definition 
Language Facility Reference Manual. 


F.8.4 Implementation-Dependent Input-Output Error Conditions 

As specified in section 14.4, VAX Ada raises the following language- 
defined exceptions for error conditions occurring during input-output 
operations: STATUS.ERROR, MODE.ERROR, NAME.ERROR, USE. 
ERROR. END.ERROR, DATA.ERROR, and LAYOUT.ERROR. In 
addition, VAX Ada raises the following exceptions fo r rela tive and 
indexed input-output operations: LOCK.ERROR, EXISTENCE.ERROR, 
and KEY. ERROR. VAX Ada does not raise the language-defined 
exception DEVICE.ERROR; device-related error conditions cause USE. 
ERROR to be raised. 

The exception USE. ERROR is raised under the following conditions: 

• In all CREATE operations if the mode specified is IN. FILE. 

• In all CREATE operations if the file attributes specified by the 
FORM parameter are not supported by the package. 


2*10 Implementation-Dependent Characteristics 




• In the WRITE operations on relative'or indexed files if the element 
in the position indicated has already been written. 

• In the UPDATE and DELETE. ELEMENT operations on relative or 
indtxed files if the element to be updated or deleted is not locked. 

• In the UPDATE operations on indexed files if the specified key 
violates the external file attributes.' 

• In the SET. LINE. LENGTH and SET. PAGE. LENGTH opera- 
lions on text files if the lengths specified are inappropriate for the 
external file. 

• If the capacity of the external file has been exceeded. 

The exception NAME.ERROR is raised as specified in section 14.4: 

S r a call of a CREATE or OPEN procedure if the string given for the 
AME parameter does not allow the identification of an external file. In 
VAX Ada, the value of a NAME parameter can be a string that denotes 
a VAX/VMS file specification or a VAX/VMS logical name (in either 
case, the string names an external file). For a CREATE procedure, the 
value of a NAME parameter can also be a null string, in which case it 
names a temporary external file that is deleted when the main program 
exits. The VAX Ada Run-Time Reference Manual explains the naming of 
external files in more detail. 


F.9 Other Implementation Characteristics 

Implementation characteristics having to do with the definition of a 
main program, various numeric ranges, and implementation limits are 
summarized in the following sections. 


F.9.1 Definition of a Main Program 

A library unit can be used as a main program provided it has no 
formal parameters and. in the case of a function, if its returned value 
is a discrete type. If the main program is a procedure, the status 
returned to the VAX/VMS environment upon normal completion of the 
procedure is the value one. If the main procedure is a function, the 
status returned is the function value. Note that when a main function 
returns a discrete value whose size is less than 32 bits, the value is zero 
or sign extended as appropriate. 


Impiememation-Oependent Characteristics 2-n 





F.9.2 Values of Integer Attributes 


The iwhi of values for integer types declared in the package 
STANDARD are as follows: 


are as follows: 


SHORT.SHORT.INTtCEk 
SHORT. INTEGER 
INTEGER 


•US . U7 
-32748 . 327(7 
-2147413(48 . 2117413(47 


For the packages DIRECT. 10. RELATIVE. 10. SEQUENTIAL. MIXED. 
IO. DIRECT. MIXED. IO, RELATIVE. MIXED. IO. INDEXED. MIXED. 
IO. and TEXT.IO, the ranges of values for types COUNT and 
POSITIVE. COUNT are as follows: 


COUNT 

posmvi.couNT 


0 .. 2147483*47 
1 .. 2147483(47 


For the package TEXT.IO, the range of values for the type FIELD is as 
follows: 


FIELD 


0 .. 2147483(47 


F.9.3 Values of Floating Point Attributes 


Attribute 


DIGITS 
MANTISSA 
1MAX r. 

EPSILON 

approximately 

SMALL 

approximately 

LARCE 

approximately 


F_ Floating Value 
and Ap p ro xim ate 
Decimal Equivalent 


16#0.1000.000#e-4 
9 536741-07 

16/0 S000.000/e-21 
2.584948*26 

l(/0 FFFF.F80#* 4.21 
1 93428E-25 


2«t2 tmptamenration-Deotnoem Cnaractanstics 






SAFE. EMAX 

127 


SAFt.SMALL 

1640.1000.00046-31 


•fffWUMMty 

2 938741-39 


SAFS.LARCE 

1640.7FFF.FC04e*32 


approximately 

1.70141E *3$ 


FIRST 

-1M0.7FFF.FFW*'* 32 


approximately 

-1.70141E *38 


LAST 

1640 7FFF. FF84* * 32 


approximately 

1.70141E*38 


MACHINE. RADIX 

2 


MACHINE. MANTISSA 

24 


MACHINE. EMAX 

127 


MACHINE. EMIN 

-127 


MACHINE. ROUNDS 

Tru* 


MACH1NE.OVERFLOWS 

True 




D. Floating ViWt 
m 4 Approximate 

• 

a n,ti ni. 

MIH9VIV 

Dtdaul Equivalent 


Dicrrs 

* 


MANTISSA 

31 


EMAX 

124 


EPSILON 

1640.4000.0000.0000.0004e-7 


approximately 

9.3132237461S48E-10 


SMALL 

1640.8000.0000.0000. OOOFc-31 


approximately 

2.39090870164461-38 


LARGE 

1640. FFFF.FFFE.0000.0004* *31 


approximately 

2.12676479226551*37 


SAFE. EMAX 

tr 


SAFE. SMALL 

1640. lono.nnon. nnoo. noo#*-3i 


approximately 

2 93S73S877US57E-39 



I 


lmpmm«ntatlon-D*c*nd«nt Charactartsttcs 2*13 




SAF1.1ARC8 


9AF1.LARCS 

1440.7FFF. FFFF.0000.OUMe *32 
1.70141183381241*38 

FIRST 

a^vtitniialy 

-1440.7FFF. FFFF. FFFF. FFSte* 32 
•1.70141183440471*38 

LAST 

1640 7FFF. FFFF. FFFF. FF8a* « 32 
1.70141183440471 *38 

MACHINE. RADIX 

2 

MACHINE. MANTISSA 

94 

MACHINE. EMAX 

127 

MACHINE. EMIN 

-127 

MACHINE. ROUNDS 

Trua 

MACHINE. OVERFLOWS 

Trtia 


AIWNm 

DIGITS 

MANTISSA 

■MAX 

EPSILON 

approximately 

SMALL 

approximately 

LARGE 

approximately 

SAFZ.EMAX 

SAFE.SMALL 
approximately 

SAPE.lARCe 

approximately 


C.FIoattaf Vatea 


Decimal lyW a l e w t 

"5 

31 


204 


164Q.4000_0000_OOn0.004»-t2 

8.881784197001E-016 

16408000.0000.0000.004e-31 
1.9444922743321-062 

16#0.FFFF_FFFF_FFFF.E04e*31 
2.S71100S70014E ♦ 061 

1023 

1640 1000.0000.0000.00#»-253 
5.3626846462681-309 

1640.7FFF. FFFF. FFFF. FQec * 296 
8.9884656743121a 307 


2-14 knptefitenwion-Dtotndtnt Characteristics 




• nmnr uia*» 

IM0.7WF..ffff.ffff. kh* zw 

I.SM4SM74312E * 907 


machine.radix 

MACHINE. MANTISSA 

machins.emax 

MACHINE. EVUN 
MACHINE. ROUNDS 
MACHINE.OVERFLOWS 



DIGITS 

MANTISSA 

EMAX 

EPSILON 

«y y twlnm> 

SMALL 

approximately 

LARGE 

iff mlw tily 

SAFE. EMAX 

SAFE. SMALL . 
approximately 

SAFE.LARCE 

approximately 

FIRST 

approximately 


1M0 4SB0 0000 0000 0000 0000 O flO ff 0000 0#t-27 
7.70371977754894341222391177033972-0034 
MM 0000 0000 0000 0000 0000 0000 0000 Offltl 
1.100tM821463791t21093431S020936E *0134 

MM.FFFF_FFFF_FFFF.FFFF.FFFF.FFFF.FFFE.O#«* 111 
4.3427420268473430639332737993000E *0133 

M3S3 

16M.1000.0000.0000.0000.0000.0000.0000.0N-4095 
8.40S257S5778023376S6S4694S433044E-4933 

MM.7FFF.FFFF.FFFF.FFFF.FFFF.FFFF.FFFF.0#«-4096 
3.S406S747678615M254287906331400E *4931 

-1W0.7FFF. FFFF. FFFF. FFFF. FFFF. FFFF. FFFF. C** * 40% 
-594869747tf7M1M82S42S79Mi33l4fl0E *4931 


lmpi»m#ntation-0«D*»v3*m Characteristics 2-1S 


1 





Attribute 

H. fleering Value 

LAST 

. approximately 

M40.7FFF. FFFF. FFFF. PFFF. FFFF. PFFF. FFFF.CW* 409* 
394MS747«7|Sl5M2S42S79tt33t400E * 4931 

MACHINE. RADIX 

2 

MACHINE.MANTISSA 

113 

MACHINE. EMAX 

HM3 

MACHINE. EMIN 

-1*3*3 

MACHINE. ROUNDS 

True 

MACHINE. OVERFLOWS 

True 


F.9.4 Attributes of Type DURATION 

The value* of the significant attribute* of type DURATION are a* 
follows: 


duration* delta 

DURATION’SMALL 
DURATION’ FIRST 
DURATION* LAST 
DURATION’ LARCK 


1.00000E-04 

r u 

-131072.0000 
131071.99*9 

1.310719999 3* 9* M I373E *03 


F.9.5 Implsmsntation Limits 


Umit Descr i ptio n 

32 Maximum number of formal parameters In i subprogram or entry 

declaration that arc of an unconstrained record type 

120 Maximum identifier length (number of character!) 

120 Maximum number of characters in a source line 

243 Maximum number of discriminants for a record type 


2-18 Implementation-Dependent Characteristics 





24* Maximum number of format parameter* In an entry or subprogram 

* declaration 

2b Maximum number of dimensions in an array type 

1023 Maximum number of library unit* and *u buna* in a compilation 

closure 1 

4043 Maximum number of library unit* and subunits in an execution 

cloture 2 

32737 Maximum number of objects declared with rSECT.OBJECT pragmas 

03339 Maximum number of enumeration literal* In an enumeration type 

definition 

69333 Maximum number of characters in a value of the predefined type 

STKINC 

63333 Maximum number of frames that an exception can propagate 

69333 Maximum number of lines in a source file 

2 21 —1 Maximum number of bit* in any object 

'The compilation closure of a given unit is the total set of units that the given unit 
depends on. directly and indirectly. 

'"The execution closure of a given unit is the compilation closure plus all associated 
secondary units (library bodies and subunits). 


Implomomition-Dtpendent Characteristics 2*17 






APPENDIX C 



TEST PARAMETERS 


Certain tests in the ACVC aske use of implementation*dependent values, 
such as the m axi m a length of an input line and invalid file names. A 
test that makes use of such values is identified by the extension .TST 
in its file name. Actual values to be substituted are represented by 
names that begin with a dollar sign. A value must be substituted for 
each of these names before the test is run. The values used for 
this validation are given below. 


Name and Meaning 


$BIG_ID1 

Identifier the size of the 
maximum input line length with 
varying last character. 

$BIG_ID2 

Identifier the size of the 
maximum input line length with 
varying last character. 

$BIG_ID3 

Identifier the size of the 
maximum input line length with 
varying middle character. 

$BIG_ID4 

Identifier the size of the 
maximum input line length with 
varying middle character. 

$BIG_INT_LIT 

An integer literal of value 298 
with enough leading zeroes so 
that it is the size of the 
maximum line length. 

$BIG_REAL_LIT 

A universal real literal of 
value 690.0 with enough leading 
zeroes to be the size of the 
maximum line length. 


Value 

119 A’s and a '1' 

119 A's and a '2' 

119 A's and a '3' in the middle 

119 A's and a '4' in the middle 

116 0’s and 0298 

115 0's and 690.0 


C-l 




1 


$BIG_STRINGl 

A string literal which when 
catenated with BIG_STRING2 
yields the iaage of BIC_ID1. 

$BIG_STRING2 

A string literal which when 
catenated to the end of 
BIG STRING1 yields the iaage of 

big'idi. 

$BLANKS 

A sequence of blanks twenty 
characters less than the size 
of the aaximua line length. 

$COUNT__LAST 

A universal integer literal 
whose value is 
TEXTIO.COUNT'LAST. 

$FIELD_LAST 

A universal integer 

- literal whose value is 
TEXT_IO.FIELD'LAST. 

$FILE_NAME_VITH_BAD_CHARS 

An external file name that 
either contains invalid 

characters or is too long. 

$ FILE_NAHE_WITH_WILD_CARD_CHAR 

An external file naae that 
either contains a wild card 
character or is too long. 

$GREATER_THAN_DURATION 

A universal real literal that 
lies between DURATION'BASE'LAST 
and DURATION'LAST or any value 
in the range of DURATION. 

$GREATERJTHAN_DURATION_BASE_LAST 

A universal real literal that is 
greater than DURATION'BASE'LAST. 

$ILLEGAL_EXTERNAL_FILE_NAME1 

An external file naae which 
contains invalid characters. 


"60 A's" 


"59 A's followed by 1" 


100 blanks 


2147483647 


2147483647 


BAD*CHARS a #.%!X 


WILD*CHAR*.NAN 


75000.0 


131073.0 

BAD-CHAR 


C-2 




$ILLEGAL_EXTERNAL_FILE_NAME2 THIS- FILE-WOULD-BE-PERFECTLY- 

An external file name which LEGAL-IF-IT-WERE-NOT-SO- 

is too long. LONG.SO-THERE 

$INTEGER_F1RST * -2147483648 

A universal integer literal 

whose value is INTEGER'FIRST. 

$INTEGERJLAST 2147483647 

A universal integer literal 

whose value is INTEGER'LAST. 

§1NTEGER_LAST_PLUS_1 2147483648 

A universal integer literal 

whose value is INTEGER'LAST + 1. 

$LESS_THAN_DURATION -75000.0 

A universal real literal that 
lies between DURATION'BASE'FIRST 
and DURATION'FIRST or any value 
in the range of DURATION. 

$LESS_THAN_DURATION_BASE_FIRST -131073.0 

A universal real literal that is 
less than DURATION'BASE‘FIRST. 

$MAX_DIGITS 33 

Maximum digits supported for 
floating-point types. 

$MAX_IN_LEN 120 

Maximum input line length 
permitted by the implementation. 

$MAX_INT 2147483647 

A universal integer literal 
whose value is SYSTEM.MAX_INT. 

$MAX_INT_PLUS_1 2147483648 

t\ universal integer literal 
whose value is SYSTEM.MAX_INT+1. • 

$MAX_LEN_INT_BASED_LITERAL 2: followed by 115 O's followed 

A universal integer based by 11: 
literal whose value is 2*11# 
with enough leading zeroes in 
the mantissa to be MAX_IN_LEN 
long. 





'V 


$MAX_LEN_REAL_BASED_LITERAL 16: followed by 113 0's followed 

A universal real based literal by F.E: 
whose value is 16:F.E: with 
enough leading zeroes in the 
mantissa to We MAX_1N_LEN long. 

$MAX_STRING_LITERAL "118 A’s" 

A string literal of size 
MAX_IN_LEN, including the quote 
characters. 

$MIN_INT -2147483648 

A universal integer literal 
whose value is SYSTEM.MIN_ INT. 

$NAME SHORT_SHORT_INTEGER 

A name of a predefined numeric 
type other than FLOAT, INTEGER, 

SHORT_FLOAT, SHORT_INTEGER, 

LONGJFUOAT, or L0NG_1NTEGER. 

$NEG_BASED_INT 16#FFFFFFFE# 

A based integer literal whose 
highest order nonzero bit 
falls in the sign bit 
position of the representation 
for SYSTEM.MAX INT. 


•l 




i 

I APPENDIX D 

* 

WITHDRAWN TESTS 


Some tests are withdrawn from the ACVC because they do not conform to 
the Ada Standard. The following 25 tests had been withdrawn at the time 
of validation testing for the reasons indicated. A reference of the 
form "Al-ddddd" is to an Ada Commentary. 

B28003A A basic delcaration (line 36) wrongly follows a later 
declaration. 

E28005C This test requires that 'PRAGMA LIST (ON);' not appear in a 
listing that has been suspended by a previous "pragma LIST 
(OFF);"; the Ada Standard is not clear on this point, and the 
matter will be reviewed by the ALMP. 

C34004A The expression in line 168 wrongly yield a value outside of the 
range of the target type T, raising CONSTRAINT_ERROR. 

C35502P The equality operators in lines 62 and 69 should be inequality 
operators 

A35902C Line 17 's assignment of the nomimal upper bound of a fixed- 
point type to an object of that type raises CONSTRAINT_ERROR, 
for that value lies outside of the actual range of the type. 

C35904A The * elaboration of the fixed-point subtype on line 28 wrongly 
raises CONSTRAINT_ERROR, because its upper bound exceeds that of 
the type. 

C35A03E & R These tests assume that attribute 'MANTISSA returns 0 when 
applied to a fixed-point type with a null range, but the 
Ada Standard does not support this assumption. 

C37213H The subtype declaration of SCONS in line 100 is wrongly expected 
to raise an.exception when elaborated. 

C37213J The aggregate in line 451 wrongly raises CONSTRAINT_ERROR. 

C37215C.E, Various discriminant constraints are wrongly expected to be 
G,H incompatible with the type CONS. 

C38102C The fixed-point conversion on line 23 wrongly raises 
CONSTRAINT ERROR. 


D-l 





T 


%■ 

> 


C41402A 'STORAGE_SIZE is wrongly applied to an object of an access type. 

C45614C REPORT.IDENT_INT has an argument of the wrong type 

(LONG INTEGER). 

* 

A74106C A bound specified in a fixed-point subtype declaration lies 

C8501B outside of that calculated for the base type, raising 

C87B04B CONSTRAINT ERROR. Errors of this sort occur re lines 37 & 

CC1311B 59, 142 &“ 143, 16 & 48, and 252 & 253 of the four tests, 
respectively (and possibly elsewhere) 

BC3105A Lines 159..168 are wrongly expected to be incorrect; they are 
correct. 

AD1A01A The declaration of subtype INT3 raises CONSTRAINT_ERROR for 
implementations that select INT'SIZE to be 16 or greater. 

CE2401H The record aggregates in lines 105 and 117 contain the wrong 
values. 

CE3208A This test expects that an attempt to open the default output 
file (after it was closed) with MODE_IN file raises NAME_ERROR 
or USE_ERROR; by commentary Al-00048, MODE_ERROR should be 
raised. 


1 


f 


D-2